Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: tmead on January 04, 2011, 11:49:55 AM
-
After previous experience with our older machine failing to move in fixture coordinates directly from home (complaints about soft limits) I added G0 G53 Z-1 and G0 G53 X-1Y-1 to the beginning of the code. This worked a treat.
We now have a second machine, and it's running a newer version of Mach3. Things seem to be different ! On the newer machine the G0 G53 Z-1 command does send the head to Z = -1 in machine coordinates, but on the first run after Mach3 startup it also sends the X and Y axes right across the bed, which is around 500mm travel. They happily then move back to machine coords -1 on the next command. These commands are being issued from a Vb button, with the While/WEnd loop between them. Further runs after the complete script is run do not elicit the same behaviour ! On this machine, I can simply remove these preparatory moves from the script and it seems happy to run in fixture coordinates right from the get-go.
Any ideas ? I was more than a little surprised to see X and Y movement as a result of a Z command !
I cannot upgrade the software on the previous machine as it is being run in a locked down environment, and any software changes will probably need extensive verificaiton testing.
if anybody wants the complete set of xml/set/bmp/macro/fixture.dat/gcode I can send it !
Tim
-
Yes, please attach the xmls etc.
Hood
-
Thanks for the prompt response. I'll stick them on this thread when I'm back in the lab tomorrow.
Tim
-
OK, here's a zip with what I think is everything. no guarantees though !
Should include : xml, set, gcode, macros, bespoke bitmaps and a photo of the machine. The Mach3 setup drives a gantry type 3 axis machine with a cylindrical cutting blade on the spindle that cuts pieces out of a slab of material. Not quite the normal CNC machining setup ! X is across the table, and Y is up and down the long axis.
Bitmaps live in the bitmaps directory, and the screens do use some of the standard bitmaps from the millbitmaps directory, but that's one benefit of Klaus' machscreen - it tells you when bitmaps are missing.
The new machine is running Mach3 version 3.042, and the older one is running 2.42 (can't be changed without a big hassle)
Please let me know if i missed anything
Tim
-
now that was quick - congratulations to whoever downloaded the file within 3 minutes of posting !
<chuckle>
Tim
-
Ok got it downloaded and installed and looking Ok, will have a look in a bit after I get the job I am working on finished.
Hood
-
Many thanks for the prompt attention Hood !
Tim
-
Which button and screen page are you running?
Hood
-
The system doesn't quite run like a normal CNC mill or lathe with a single page for a particular function, they flow in sequence to try to minimise the skill level and training requried of the operator.
The system starts up with page 1, and on pressing the image button the axes home and DROs/labels/variables are initialised and then a prompt pops up asking which format to cut. Selecting 'slab' brings up page 2 to assess the position of the clamp jaws with a colour discriminating sensor (funky piece of kit from Omron and not ridiculously expensive). The issue comes when the 'find clamps' button is pressed. I've got a feeing that the file I sent has the G53 command commented out to avoid the movement, so have attached a slightly earlier version (18) of the screen set.
When the clamp assessment is complete, screen 3 is displayed to allow an operator to set up the cutting order for the required quantities of the four sizes of material.
Tim
-
Yes it did have the G53 commented out and if I recall a Home Z command, well thats if I was looking at the correct button ::)
Hood
-
I have simulated the Home switches and get as far as the Slab page but wonder whether there should be any inputs active?
I am really crap at VB so will have to take time to try and study this, will have a look when I get home tonight.
Hood
-
Yes, the 'find clamp' button in version 20 had the following commented out:
' Code "G0 G53 Z-1" ' preparatory move of Z in machine coords
' Hold
' Sleep(100)
' Answer=MsgBox("OK ?",0)
The G0 G53 Z-1 was the original, with a call to the 'Hold' subroutine, which is a While/Wend loop.
The extra Sleep 100 was added just in case, and didn't change the action
The messagebox was an extra debug attempt just to separate out the code segments and isolate the issue.
Tim
-
Shouldn't need any other inputs at all.
To simulate the issue (or not !) you shouldn't need any other inputs, as it occurs before the sensing is active. It may get confused later in the script when G31 is called, although if no probe is connected it should either interpret that as a sensor failure or failure to detect, both of which are trapped in the code.
If no driver is installed you need to press the 'simulate' button on page 1 to set it to ignore the sensing, as G31 doesn't work on development machines without the driver.
Tim
-
Ok heres wat I see here, because I dont have a machine I obviously dont see the axis moving so I have added OEM DROs 83,84,85 to the main page so that I can see the DROs counting.
I press initialise button and Z moves, I simulate the home switch and Z zeroes then Y and it does the same then X.
X and Y then get set to minus 1 but Z stays Zero. Slab/Disc message comes up I press Slab and the page is displayed, press Find Clamp and Z moves to G53 Z-1 then I get message box asking for OK. I press Ok and X and Y move to minus 2.
Is that the part where its going wrong or do you see X and Y move at the same time as Z is going to G53-1?
Hood
-
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
-
I will try again when I get home and see if I get the problem or if it works.
Do you possibly have any plugins or brains enabled which could affect things?
Hood
-
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
-
What exact version of Mach are you using?
Hood
-
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
-
Ok I was using 040 I think, will try with the versions you have when I get home.
Hood
-
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
-
G53 has always been rock solid here too. Sounds almost like the axes are not referenced prior to the G53. I know if I don't reference the machine prior to a G53 I get some unexpected results.
-
When you do anything in VB that causes DRO's to change values, you need to give them time to actually update. Sleep(250) 1/4second should be enough.
-
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
-
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
-
SOUNDS like you need to develope a Plugin for mach instead of the VB approach.
(;-) TP