Axis runnaway?

[Treb63]

Hi,
Many thanks for this professional piece of programming it has brought Mach back to my area of expertise (32 years cnc service engineer) and away from the usual Router style of machine interface.

My question is I am experiencing a strange situation which could be a Mach issue and not a MSM issue that being, I have a x/y arcade style joystick set to jog the x and y axis via the oem codes and an input via my BOB, when I jog at say 15% everything is fine when I select 100% via the 'shift' key plus the joystick input it speeds up the axis movement as it should which is great however if I select step mode and say 0.1mm increment all works well until I select the shift key then the direction input (to speed up the step move) if I let go of the shift key before the step input the axis keeps moving in that direction without stopping in rapid requiring a very rapid e stop and potentially a lot of damage.

I suspect this may be at fault with mach itself or the U300 board which up till now has performed faultlessly but thought I would just check here to see if anyone else has found the same effect?

regards
Rob

[DaveCVI]

Hi,
Many thanks for this professional piece of programming it has brought Mach back to my area of expertise (32 years cnc service engineer) and away from the usual Router style of machine interface.

I'm happy to hear that you like it!

My question is I am experiencing a strange situation which could be a Mach issue and not a MSM issue...

OK, I'm thinking this is not a MSM issue. Here's the logic: the only entity that is handling key strokes
is Mach itself. In fact, there is no mach interface to let a script intercept keystrokes and try to handle them. This is why there are keys that I can't "fix" in MSM to act as key in windows should (example: the tab key should shift between DROs, but mach has it permanently assigned to open the fly out tab).

... that being, I have a x/y arcade style joystick set to jog the x and y axis via the oem codes and an input via my BOB,

So there is just one input pin being used by the jostick? That seems odd to me as it would mean that the
the joystick is either on or off. If that is so, how does the joy stick tell mach what axis and which direction to jog?

when I jog at say 15% everything is fine when I select 100% via the 'shift' key plus the joystick input it speeds up the axis movement as it should which is great

OK, That's the same action Mach does for arrow key jogging.

however if I select step mode

The action of step mode is further dependent on the MPG mode that is set.
If you are in "S" (single step) in the MSM jog panel, you should get one step - period - no matter how many input events there are (this is commonly how a MPG does single step per pmg click). In "M" mode (multi-step) you should get 1 step for every input event.
AS far as I know, these modes were created for MPG control. Perhaps you don't have an MPG defined in ports & pins (as you have a joy stick) - in that case all kinds of odd stuff could be happening as you would be sending MPG commands without an MPG - that's the type of thing that I think mach should fault on, but it often try's to do the proverbial 'right thing" - but goes wonky instead.

and say 0.1mm increment all works well until I select the shift key then the direction input (to speed up the step move) if I let go of the shift key before the step input the axis keeps moving in that direction without stopping in rapid requiring a very rapid e stop and potentially a lot of damage.

[/quote]
so to see if I understand this:
1) shift key down
2) direction key down
3) direction key up
4) shift key up
works OK?

but
1) shift key down
2) direction key down
3) shift key up
4) direction key up
sounds like this causes the "Direction key up" event to not be seen in mach - and that would cause mach to act as if a jog key is permanently held down. Not a good situation.

This sound at first pass like a mach bug to me. But I'm not 100% sure I hace the details correct yet.
What has be uncertain is the action of the joystick and how it's telling mach what axis to jog.
If this is via the Mach OEM code for jog axis, then I have no idea how or even if mach is supposed to be handling the interaction between a shift key and an OEM jog command.

I suspect this may be at fault with mach itself or the U300 board which up till now has performed faultlessly but thought I would just check here to see if anyone else has found the same effect?

regards
Rob

Sine the motion boards do not handle keystroke input to mach, I'd guess mach over the U300.
However, if this is a Chinese "U300", well I've had real bad luck with a lot of the chinese boards - they tend to weird stuff and I've thrown more than one in the scrap heap.

I'm curious, are you running MSM pro and have you done any probing operations?
I know many of the cheap Chinese motion boards fail to execute probe commands correctly. So if yours is working I'd like to know that.

Dave

[Treb63]

Hi Dave, I will get a better explanation of the keystrokes and input method when I return home on Friday, the joystick I'm using has 4 micro switches in its base and is set for four pins and therefore four different oem codes, will check my set up and get back to you.

The board I am using is a UC 300 and to date has been perfect it handles the probing very well and only one crash of the probe so far which was my fault using a normally closed probe and a normally open touch plate on the same input and swapping between high or low in ports and pins when I wanted to use either not realising that a restart may be necessary for the swap to work properly, I have a normally closed table tool length switch now and all works well.
I will be trying to use a n/o plate soon with the two input methods on different pins and see if it works.

I have quickly scanned the mach support boards and this issue of unwanted movement going from jog to step mode is quite common with different bobs etc so I guess it is inherent to mach, will let you know more info soon.

Regards
Rob.

[DaveCVI]

hi,

Hi Dave, I will get a better explanation of the keystrokes and input method when I return home on Friday, the joystick I'm using has 4 micro switches in its base and is set for four pins and therefore four different oem codes, will check my set up and get back to you.

Ok, that makes more sense to me - then it's an obvious mapping of each switch to an input line and each line can do an oem code for an axis and then + is separated fro - for direction.

The board I am using is a UC 300 and to date has been perfect it handles the probing very well and only one crash of the probe so far which was my fault using a normally closed probe and a normally open touch plate on the same input and swapping between high or low in ports and pins when I wanted to use either not realising that a restart may be necessary for the swap to work properly, I have a normally closed table tool length switch now and all works well.
I will be trying to use a n/o plate soon with the two input methods on different pins and see if it works.

FYI - latest versions of MSM now support interfacing the probe and touch plate on separate input pins.
Grab the latest manual and look for "two signal" interfacing.
This will handle the problem you were running into without needing create external electronics to "or" the active high probe and active low touch plate signals.

I have quickly scanned the mach support boards and this issue of unwanted movement going from jog to step mode is quite common with different bobs etc so I guess it is inherent to mach, will let you know more info soon.

Regards
Rob.

It does have that feel of being a mach bug....

Dave

[derek]

Hi,
Many thanks for this professional piece of programming it has brought Mach back to my area of expertise (32 years cnc service engineer) and away from the usual Router style of machine interface.

My question is I am experiencing a strange situation which could be a Mach issue and not a MSM issue that being, I have a x/y arcade style joystick set to jog the x and y axis via the oem codes and an input via my BOB, when I jog at say 15% everything is fine when I select 100% via the 'shift' key plus the joystick input it speeds up the axis movement as it should which is great however if I select step mode and say 0.1mm increment all works well until I select the shift key then the direction input (to speed up the step move) if I let go of the shift key before the step input the axis keeps moving in that direction without stopping in rapid requiring a very rapid e stop and potentially a lot of damage.

I suspect this may be at fault with mach itself or the U300 board which up till now has performed faultlessly but thought I would just check here to see if anyone else has found the same effect?

regards
Rob

Hi Rob
I have a UC 300 and a couple of UC 100's. The runaway issue you are describing is a bug in the UC motion controls. It was also a problem with my USB smooth stepper. I let Balazs know about it but it wouldn't hurt if you prodded him as well.

I had probing problems early on and reported it but never had a chance to try out the updated plugin. I came to this forum as I am gearing up again to try probing. So it sounds like your having good results with the probe.

Derek

[DaveCVI]

Hi,

Hi Rob
I have a UC 300 and a couple of UC 100's. The runaway issue you are describing is a bug in the UC motion controls. It was also a problem with my USB smooth stepper. I let Balazs know about it but it wouldn't hurt if you prodded him as well.

Do you have a URL handy for the web site for these controls?

I had probing problems early on and reported it but never had a chance to try out the updated plugin. I came to this forum as I am gearing up again to try probing. So it sounds like your having good results with the probe.

Derek

FYI- then a motion device fails a MSM probe op, a quite common situation is that the device will do a G31 in G90 (abs coords) mode but not in G91 (relative coords). For some reason, motion device designers have a blind spot re G91 operation. MSM does both G90 and G91 probe moves within it's probing routines.
A quick test is to use the MDI line to do some G90 G31 and G91 G31 moves and see how the device acts.

Dave

[derek]

Hi,

Hi Rob
I have a UC 300 and a couple of UC 100's. The runaway issue you are describing is a bug in the UC motion controls. It was also a problem with my USB smooth stepper. I let Balazs know about it but it wouldn't hurt if you prodded him as well.

Do you have a URL handy for the web site for these controls?

I had probing problems early on and reported it but never had a chance to try out the updated plugin. I came to this forum as I am gearing up again to try probing. So it sounds like your having good results with the probe.

Derek

FYI- then a motion device fails a MSM probe op, a quite common situation is that the device will do a G31 in G90 (abs coords) mode but not in G91 (relative coords). For some reason, motion device designers have a blind spot re G91 operation. MSM does both G90 and G91 probe moves within it's probing routines.
A quick test is to use the MDI line to do some G90 G31 and G91 G31 moves and see how the device acts.

Dave

Hi Dave
Here is a link to their web site
http://www.cncdrive.com/index.html

Click on products and scroll down to motion controllers.

I passed along the info you gave me originally to them and they made changes accordingly. I just never had a chance to test it. I'm getting a bit of a breather right now so I'm picking it up again.

Derek

[Treb63]

Hi Both,
Just had my delivery of a Tormach passive probe and have been calibrating and setting it up this morning, no problems at all. It is repeating to less than 15 micron even taking it and out of the machine on a repeatable holder (R8 and collet) so in a word great, I haven't tried many of the routines apart from calibration, centre find, edge, corner and z surface find but so far has worked perfectly looking forward to using some of the other screens for slots etc

Now onto the original problem, only using the computer keyboard the problem will manifest itself so my additional wiring and inputs should not be an issue here running the latest version of MSM pro with a licence

With the 'Jogging' and 'Cont' LEDs lit the shift key lights the '%' LED pressing the left or right arrow will move the X axis in Rapid jog. (all correct)

With the 'Jogging' and 'Step' LED's lit NO shift button the left or right arrow will step the x axis the desired increment. (all correct)

With the 'Jogging' and 'Step' LEDS lit pressing the shift button will also light the 'Cont' LED (?) pressing the L or R/H keys will jog the axis in Rapid and ignore the step amount letting go of the shift key before the L or R/H key is released will leave the machine in a runaway condition.

Hope this clears it up somewhat.

I will attempt to get in touch with the producer of the UC 300 board and see if this problem can be reproduced on his equipment etc etc. Apart from that so far the UC 300 board has been fantastic giving more Inputs and Output possibility's with its 5 port connections and on board motor control than its price point would suggest it should be capable of. It should be easily possible to run two machines from this one board.

[Treb63]

HI,
Wow one quick email and it seems to be identified and on route to be sorted, hopefully.
So far still impressed with this product replying to an email with results on a Saturday afternoon not many company's care that much.
Hopefully Derek a fix will appear soon.

Rob
--------------------------------------------------------------
Rob,

Thank you for your e-mail and for letting us now about this issue.

I just tested what you described and it really causing a problematic situation.
Also I tested the same with our UC100 controller and it looks that the same issue does not present on that device.

So, this makes me beleive that the problem is a bug in the UC300 firmware.

I'm passing the problem description to our programmer now who will correct the firmware soon.

I will let you know as soon as the bug fix gets done.

Thank you again for your help improving our product!

Best Regards,
Balazs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[DaveCVI]

Thanks for letting us know how the vendor responded. I'm personally partial to companies that try hard to make a quality product.
Dave