Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Tweakie.CNC on June 28, 2010, 02:58:07 AM
-
I am having an issue with switching output #1 with the commands E1P1 and E1P0.
For most of a program it works just fine then suddenly gets confused (particularly with short moves) then returns to working just fine again.
Despite much experimentation I have not been able to get to the bottom of this or find the cure.
If anyone has experienced this problem and discovered the reason or found a cure I would be most grateful to learn the answer.
I have attached a simple GCode which exhibits this problem.
Thanks,
Tweakie.
-
Just curious the reason you are using this? If its for no delay operation of turning on/off your laser I wonder if M10/M11 would work better?
Hood
-
Hi Hood,
Thanks for your response - Yes it is for no delay, or switching at the point of the axis movement, for a laser.
Funny enough the M10 /M11 combo also suffer similar, although slightly different, behavior. There is definitely something strange here as I have tried different computers with the same result.
I have attached a modified (m10/m11) version of the earlier GCode just in case anyone wants to see the difference.
Tweakie
-
Hi Tweakie - don't know if this is any use to you but a while back I spent a bit of time looking at reducing the delay after switching outputs. http://www.machsupport.com/forum/index.php/topic,13206.msg86699.html#msg86699 (http://www.machsupport.com/forum/index.php/topic,13206.msg86699.html#msg86699) (post #11)
Cheers
Ian
-
Hi Ian,
Thank you for the link, which I had not seen before. I have just given this a try (got quite excited) and although it may speed the Output # ? switching time there is still a delay before the next line of code is executed when using M3 or M1001.
With cutting acrylic this delay is unimportant to me it is just with engraving where the depth varies at the start and end of the kerf.
It is so annoying that the E1P1/E1P0 works so well... 'when it works'. :( :'(
Tweakie.
-
although it may speed the Output # ? switching time there is still a delay before the next line of code is executed when using M3 or M1001.
Hi Tweakie - The timings I've given in the thread (via scope) were between the edge of the ouput going active and the edge of the first step pulse on the next line that commanded movement. i.e. NOT the time it took the output to go active. Worked every time for me and like I say I got it down to ~ 0.05 seconds, but looks like one of those one's that don't work for everyone for whatever reason.
Cheers
Ian
-
Hi Ian,
Thanks for the info, I must look into this a bit more then. I didn't actually measure anything, just looked at the results in a piece of scrap perspex.
Just out of curiosity and assuming you have a better memory than me, what acceleration figure were you using for your X -Y axis ?.
Tweakie.
-
5000mm/sec^2 (velocity 15000mm/min)
-
fingers too fast for brain - why does that make any difference?
Ian
-
Hi Ian,
fingers too fast for brain - why does that make any difference?
The faster an axis takes off from a standing start and the quicker it stops the less drawn out the unwanted increase in depth of cut at the start and finish of the kerf becomes. (on wood this is shown as a dot at each end of a line - quick acceleration, small dot - slow acceleration, bigger dot).
5000mm/sec^2 (velocity 15000mm/min)
You must have super low mass in your axis to achieve that Velocity and acceleration. My poor little steppers might just about manage a squeak. ;D
Tweakie.
-
Tweakie - can you post your xml please.
Ian
-
OK took a look at this on the scope and here are some of my findings - not sure it's any real help though.
1) a G1 followed by a G0 blends - IMHO this is wrong
2) a G0 followed by a G1 doesn't - IMHO this is correct
3) sometimes E?P1 doesn't activate - unable to find out why. In your example the lines that don't activate are lines: 59, 63 and 67.
4) E?P0 deactivates at the END of a blend - but because of 1 this leads to perhaps unexpected and unsatisfactory results.
5) The time difference between an E?P1 activating and the first step pulse is ~ 0.05ms
6) The time difference between an E?P0 deactivating and the last step pulse is ~ 0.05ms (but because of 4 and 1 this can lead to unexpected results)
7) Not using E?P0 would mitigate 1) becaue blending does not cross other methods of activating outputs.
E?P? was apparantly designed by Art to allow on/off switching DURING a blended move. Your example doesn't appear to use this functionality and so because of 1) you suffer the downside without any apparant upside.
Ian
-
Thanks Ian for taking the time to look at this, your findings are much appreciated.
Tweakie.
-
Just for what it is worth this has been an ongoing problem and gets worse with later vers of MACH. I think there was a change in how Mach/VB relates to each other and it has made things worse for VB/Gcode interactions.
I can remember back when you NEVER needed a wait state and got repeatable results . NOW that same code will NOT work at all. It stumbles all over itself and skips code to boot. Same code same computer new VER.
Just for what it is worth, (;-)
-
Terry - can you expand? There is NO VB in Tweakie's E?P? code. The two main issues as I see it are 1) and 3) in my post above.
Ian
-
Ian the M3 and other Mcodes run in the VB side. IF you call any macro it could be VB releated
That should have read Gcode/VB interactions(;-) At a certain Ver time line large delays started to appear in Gcode/VB. Pre V.019 things ran very well and predictable. After that things took a lot of revamping to even run much less be reliable.
BUT that is just my findings.
(;-) OK I must have been absent one day at school WHAT is E1P0/1????
-
OK I found it in my OLD notes. It was the trick Art added in for Plasma OEMs
-
Perhaps the future is not looking good for Mach control of lasers.
Do you have any ideas of how Version 4 will perhaps handle the E1P0/1 ?
Thanks guys, I really appreciate your time on this one.
Tweakie.
-
I am not in the V4 loop so maybe someone else knows
-
Tweakie have you back up versions to find a stable version that will still work? I know in plasma the standard is pretty much V.020.
Justa thought but have you though about using an axis DIR pin output to drive the laser?
-
Thanks for the suggestions Terry - I have probably got most earlier versions so this is something else for me to try.
I started out using the Z axis direction pin but that has the delay of the small amount of 'would be' z travel, so I then moved on to the M11/M10 combination. It was in an old thread that Brian mentioned the E1P0/P1 and that has been quite good if it worked all the time (but of course it doesn't :'( ).
Going back to the Z dir pin if I could move the 'Z minus' instructions to the start of the next G1 X or Y axis movement then the laser would be triggered at the time of movement but this would not help with switching it off at the end of the movement and modifying existing GCode would possibly start to become complicated. I am really trying to keep this simple by using the same GCode that would be used for engraving and just replacing the Z codes but perhaps this is not going to be possible.
As said before I do appreciate your time.
Tweakie.
-
HUM I would have though that being the pulses would be loaded into the output buffer that the pulses would be pretty much instantanious. AND with CV on there would be no possible delay.
Guess not???
Were you using a 1 step size move with the Z axis to control DIR?
-
Were you using a 1 step size move with the Z axis to control DIR?
It was a while and I will have to look up some earlier code examples for this but from memory I think it was more than just one microstep.
Tweakie.
-
Hi Guys,
I think Terry's suggestion has solved my problem.
By revisiting the use of the Z axis direction pin method of control I have found that previously I had been using a Z movement of +/- 10 microsteps. Changing this to a distance of 2 microsteps total movement (+/- 1 microstep) has made dramatic improvements in the work quality. (not sure if it will work at +/- 1/2 microstep or 1 microstep total but I will give this a try).
It needs a bit more testing but so far the results are absolutely brilliant, there is no sign of overburn at the start or ending of long or short lines and the cut depth in acrylic is pretty constant at the start and ends. It is a shame I don't have a close up lens for my camera because the difference is just so great it really deserves a picture.
Thank you all for your assistance and time spent on this - I think I can now safely ditch the E1P1/P0 and M11/M10 etc. etc.
Tweakie.
-
Tweakie - can you post a copy of your latest gcode using the dir pin method and a copy of the M10/11 version. Obviously it's good you have a solution that's working for you but it's still a kludge. I'm thinking this problem has to do with CV and I'd like to scope your latest solution just for fun to see if I can home in on exactly why it's better than M10/11.
Thanks
Ian
-
Thanks Ian,
Due to location of my equipment I am unable to measure the pulse timing at present but I would be most interested to know what it is.
M10 and Z control files attached.
(I am changing the Z dir pin, in ports and pins/motor outputs, to my laser trigger pin16).
Tweakie.
-
Tweakie I don't think 1/2 step will work as mach will HOLD the move until the next move. You will need a minimium of a 1 step for mach to apply the move.
Ian I think the problem does lies with VB or at least the VB/GCODE interface. Mach used to behave MUCH better than it does now. I think the attempt to fix the VB sync problem has caused delays. ALSO you used to NOT have to use HOLDS to make the VB/GCODE work correctly, it just did . NOW it takes a ton of wait states to make it work AND it is different with every other computer as to how to make it work sometimes.
There has to be a better way(;-) I would not be apposed to ditching the VB for VB/GCODE and goto conditional Gcode and ONLY use the VB for user macros for I/O and internal functions such dros,led,button controll. BUT the brains do a far better job in most of these areas.
(;-) I think we have LOST sight of mach as a machine controller and have converted it to a DOALL piece of motion software. AND we "LOST" machine function in the process
The Dir pin pulse is included in the pulses sent to the buffer so there will be no delay from the last pulse of the Axis move to the stop laser pulse.
-
Ian I think the problem does lies with VB or at least the VB/GCODE interface.
Terry - I agree that there are BIG problems with VB and it's interface to Mach - BUT - the E?P? code that Tweakie posted in his first post doesn't use VB AT ALL - so how can the issues he raises be anything to do with VB?
Ian
-
Ian we don't know HOW ART made it work (;-) It could very well be VB based code ????? OR it may use the VB interface to the Gcode side .
We do know it suffers that same type of random delay problem as VB does now.
-
Hey Guys,
Just as a by the way thing....... If the command E1P0 is changed to E1P0M5 then the code runs perfectly every time on the few examples I have tested - But the turn off delay is increased again almost up to the levels of the M10P1.
Don't suppose this helps but thought I would mention it.
Tweakie.
-
HUM that is interesting. Art stated early on that the E1p0/1 was to be ONLY Used on a line by itself. If used on mixed line it would error out as bad code syntax error.
-
TWEEKIE, Question on the E1p0(;-) How are you generating your Gcode for laser???
-
The example I have been using was created using a Roland engraving program which outputs HPGL, this was then converted to GCode. Then I edit the Z moves to the E1P0....
Tweakie.
-
OK Thanks, I found a slight M5 delay in sheetcam gcode output and was wondering if you were useing that.