Ok just tried here at home with the 042.040 revision and all is OK.
I will go and see if an older version screws it up.
Hood

Just tried with 022, 025 and 026 versions and all is as before. Press button Z homes, then Y then X then X and Y get set to -1 then slab option and press button and Z goes -1 then OK appears and press it and X and Y go -2 then OK again then X and Y start moving.
Hood

That's very strange !

i couldn't find any plugins on either machine, so the difference between the response to the first time the button is pressed and later presses is very odd.

Looks like I'll just comment out the G53 lines, as they are the issue.

Tim

You need to try something . Startup as normal. Then run your sequences manually from the MDI. This will eliminate any VB problems. IF everything from the MDI run is correct then we know where to start looking.

In the later versions Mach has a weird sense of humor when it first starts up. I think it has to do with windows still doing some house work internally that interferes with the VB side. Some machines see it some don't.


Also in your VB code you MUST do the While Ismoving() Wend right after the Movement line. DO NOT hop out to a hold sequence as you can easily mess up the code sync and confused mach in the process. 

Just a thought, (;-) TP

OK, this just gets wierder !

Running the script in single steps works just fine, which also leads me to think it's a script/gcode sync type issue.

If I start up Mach3 and press the button on the first screen to home the axes and set up the DROs/variables and then enter GCode manually on the second screen this is what I see on the development laptop - no machine connected.

1. G0 G53 Z-1 causes the Z axis to head for around +25.5 (repeatable figure)
2. G0 G53 X-2 Y-2 causes the X and Y axes to head off to large positive values (again - repeatable positions)
3. Setting a a workpiece with G59 P.. seems to sort it all out, and subsequent G0 G53 commands work as expected.
4. issueing a G59 P13 command first means that subsequent G0 G53 commands work as expected.

I've added a 'sleep 1000' into the script after the G59 P13 and now it works a treat.

The 'hold' subroutine is at the bottom of the script and is just a while/wend loop that is called. It didn't make any difference when I put the while/wend in the code vs. in the subroutine.


This is very odd, and I now realise that what i thought was a script error a few days ago that caused a mildly bend sensor bracket was actually the same thing. G53 seems very unreliable, and I certainly wont be using it in recovery sequences or anything that could result in collisions.
It's a real shame, as there are times when being able to confidently move single axes in machine coordinates is a very useful technique.

Happy to have a workaround, but confused as hell about what is actually going on here !
It's late and I'm off to bed !

Tim

The 'hold' subroutine is at the bottom of the script and is just a while/wend loop that is called. It didn't make any difference when I put the while/wend in the code vs. in the subroutine.

without the
While IsMoving
Wend
immediately after a movement, I've seen the next lines get skipped completely. It's very possible you're sub will be ignored, probably when you least expect it.

G53 seems very unreliable, and I certainly wont be using it in recovery sequences or anything that could result in collisions.
It's a real shame, as there are times when being able to confidently move single axes in machine coordinates is a very useful technique.

I use G53 in my auto zero routines and it's 100% reliable. If not, it would definitely cause a crash. And I have several people using my routines, also with 100% reliability.


Just thought of something. Is your Machine coordinates LED on?

Thanks Gerry,

The possibility of skipping over lines of VB is a concern - I had considered the possibility of skiping lines of GCode if the relevant pauses weren't added. It makes the code way more untidy to repeat that loop over and over thoughout rather than collecting it in one place. Never mind- I can do that.

However - this issue doesn't seem related to scripts from buttons. I get some very wierd results from entering G0 G53 .... commands in the MDI until I put in a G59 P.. to set a fixture coordinate system. Then it's fine. That's what I've put in the code too, and with a sleep (1000) after the fixture selection everything is just dandy. The sleep is critical, and I haven't tried shorter pauses.

I'm now very wary of G53, as scripting a command such as G0 G53 Z-1 and then seeing X and Y move long distances during the Z move is something that I cannot risk. I will try to capture some screen video from my development laptop to demonstrate what I'm seeing.

Recovery routines now have to use a home move in Z before any X or Y commands to retract the tool. I can't rely on fixture coordinates as the possibility of a crash or jam causing lost steps is too significant.

Tim

Sorry - to answer your machine coordinates LED - I'm using DRO 83/84/85, which are not multi-purpose to avoid the need for operators to understand the coordinate systems.

Tim

A bit more experimenting and it is definitaly cured by adding a sleep command directly after the G59 P13 in all of the cases where I've used it and odd motions had appeared (there are other buttons when I've tried it, and thought I had a script error, so moved over to re-homing the Z axis first rather than using G53). I hadn't thought of a need to add a pause after the fixture selection, only after commands involving moves.

If I create a GCode (tap) file with the same commands from my script and load/run it there is no issue, it all runs normally. I guess I could pop the preparation gcode in a macro file and call it, although the rest does need to be run from the script as varibles are calculated as required.

The odd movement seems to be related to the need for lots of pauses in the script to allow the gcode commands to work properly.


The wierdness seen using G53 on the command line i still cannot understand, so I will have to ignore for the time being !

Tim

Running it from a gcode file AND from a VB file are two totally seperate things.

The Gcode file will be very stable BUT the VB (;-) as you have seen requires YOU to try and keep it synced.

Don't worry about pretty code worry about making it work right (;-) TP

I try to NEVER run a gcode from VB if at all possible.

Here the G53 has always been rock solid no surprises. NOW one thing to remember IS you must REF home the machine BEFORE mach truely knows where anything really is. IF you are just testing and DO NOT HAVE the home switches active then MACH canand will  assume that it is somewhere where it is not. UNTIL you refhome you should not run the G53 and expect it to know where it is.

I would try a complete and total reload of mach. Delete the driver manually and all the files then reload a fresh download. Rebuild the XML manually and start again.

Been there done that, (;-) TP