Messages

21

General Mach Discussion / Re: G53 oddity

« on: January 06, 2011, 05:52:23 PM »

the screen set forces a sequence of actions from the operator.
* Page 1 only has one option to reference all axes and make a small move. DROs are not updated or changed except as a result of axis moves.
* Page 2 is displayed, where all the fun began. This only has two buttons, and only one does anything if the script is not running.
* The main button script starts by trying to make a couple of preparatory moves, based on history with a previous machine running an older version of Mach3. These were G53 moves as the previous machine seemed to object to moving in fixture coordinates away from machine zero after reference all. These now work, after adding a G59 P13 and a sleep 500 before the g53 moves.

Tim

22

General Mach Discussion / Re: G53 oddity

« on: January 06, 2011, 12:53:50 PM »

The application we are running is for cutting shapes from a bulk material in a produciton environment using a specially design ed cylindrical blade, and is not a not a normal CNC machineing application. The script calculates variables that are then used to position G81 drilling cycles. This is done based on the operator requested combination of the four sizes of bores, and any combination must be available to the operator. This means there is no way round issueing GCode commands from the VB. None of the canned drilling commands that are constructed using VB scripts have been a problem at all, it's all been in the setup and recovery routines, where I know now I'd have been much better loading a small gcode file !

The machine refernces all axes to switches at the beginning of a run, and the operator will not be able to proceed until this is compelete.

Adding a sleep 500 after the G59 command has made the G0 G53 totally reliable now. I did not expect to have to worry about the synch when issueing GCode setup commands like this - now I know better !

Tim

23

General Mach Discussion / Re: G53 oddity

« on: January 06, 2011, 06:26:45 AM »

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

24

General Mach Discussion / Re: G53 oddity

« on: January 06, 2011, 06:16:00 AM »

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

25

General Mach Discussion / Re: G53 oddity

« on: January 06, 2011, 04:55:26 AM »

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

26

General Mach Discussion / Re: G53 oddity

« on: January 05, 2011, 06:54:31 PM »

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

27

General Mach Discussion / Re: G53 oddity

« on: January 05, 2011, 02:41:44 PM »

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

28

General Mach Discussion / Re: G53 oddity

« on: January 05, 2011, 10:54:57 AM »

development laptop is 3.043.022, machine PC is 3.042.025

Both are showing the same issue. However, the $64 000 question is: what will happen when I install the screenset on the production machine at realease 2.42 ? Now anyone that can answer that really deserves a fresh carrot !

Tim

29

General Mach Discussion / Re: G53 oddity

« on: January 05, 2011, 10:30:12 AM »

nope, the system is a squeaky clean, fresh install, never been used for anything else.

I've looked for brains, tool offsets and have pulled out hair trying to track this down. Hadn't thought of plugins though, but definitley haven't run any on purpose. I'll check on that. Strange that two machines would have the same issue though....

Interestingly - if I run the button script from the code window (edit button script) and single step through, it works exactly as expected.

I'm just fortunate that this doesn't break anything. and is therefore a bit on an intellectual curiosity. There are other points in the cycle where an unexpected X / Y move would be costly.

Tim

30

General Mach Discussion / Re: G53 oddity

« on: January 05, 2011, 10:00:45 AM »

Yep, that all looks as expected, except you didn't get the spurious movement in X and Y during the Z movement to -1 (machine). The OK message was just part of my debugging to try to isolate what was going on.

It does the same on my code development laptop too, moving to around x = -300 y = -500 (machine coords)

If you press the Interrupt button as it is performing the movements it will stop at the end of a completed sensing pass. Subsequent presses of the Find Clamp button work exactly as you describe on the machine and development laptop, without the large movement right across the table and back, which is very strange.

I really don`t undersntand now !

Tim