forum.cncdrive.com

Hello,

I have a very strange problem, a spurious one.
Sometime, one ligne of code is skipped. A very frequent sometime.

UCCNC : soft 1.2104, firmware: 1.0310 Hardware: 1.0 Device type UC300ETH_5LPT
Machining 2.5D, one tool for the whole machining

For now the skipped line is always of the form (second one)

G[Not 0] Xnx Yny ....
G0 Xnx Yny Z2.0 (THAT ONE IS NOT EXECUTED)


Like in :
.....
G1 X-0.956 Y230.201 Z-6.5 F1000
G1 X-0.99 Y229.014 Z-6.5 F1000
G1 X-0.99 Y228.276 Z-6.5 F1000
G1 X-0.992 Y228.242 Z-6.5 F1000
G1 X-1 Y228.242 Z-6.5 F1000
G0 X-1 Y228.242 Z2 ( That one seems to be skipped, sometimes)
G0 X428.742 Y250 Z2.0632 ( That one then kills the stock ! )
G1 X428.742 Y250 Z-0.8658 F300
G1 X428.742 Y250.008 Z-0.8657 F1000
.......

Then my stock is spoiled. 3 times *** at different places *** in 3 successive machinings.

INFO : Maybe, but i cannot check, the probe was hit : the detector device is hanged to the Z axis when not in use.
But i am sure to have NOT set JSP. Anyway, that is for jogging only, isn't it ?

Q 1) G0 after G[non-0] sometime ommited ?
Is there a possibility that a line was skipped ? I doubt. Can i have access to a kind of log, showing what line are correctly processed,
and possibly not sent to the UC 300 ?
For example, i suppose you do not send the comments or the successive lines which does not do anything, like in :
G0 X10 Y20 (good, usefull)
G0 X10 Y20 (useless)
G0 X10 (useless)

But what if, Processing a G0 after some G[not 0], you may 'think' that line is not needed ? (under some obscure circumstances !)
For sure, knowing the uccnc is widely used, i suppose there is one or more "local" specifics here in our international cosmic exploration plant !
WIN7 64 up to date, plenty of 8Go RAM and an I3.

Q 2) Possible UDP lost ? (unlikely)
I started my favorite wireshark, and noticed the whole protocol use UDP.
Is it possible that a command may be sent with UDP, lost somewhere, then got no acknowledgement, but the process go on...
Frankly i doubt, but i prefer to make sure, then i ask. Don't bit me, i wear glasses.
I just setted up a vacuum pump, and i suspect that one to radiate EM.
This just to be sure : if some UDP datagram are lost, statistically, there should be some trouble
with the continuous flow between the pc and the uc300, used, obviously, to collect IO statuses and positions.

Q 3) What do you think about using Codesync then getposXYZ() to check the coherence ?
As of now, my plugin can send the gcode, line by line with execsync. I could then stop after the first G0 after non-G0 and ask for a confirmation.
But then maybe you have some hints : what should i check ? If i can catch the event, i can then collect datas for analysis.
My Idea was to send the lines, but after the first G0 after non-G0, to collect the machine and relative positions,
and check if they are what they are supposed to be.
I notices 20ms between 2 position reports. That explains a lot to me : there is maybe a plugin loop cycle to ignore, in order to let UCCNC respond with the good, updated position. As of now, everything is ok if i leave a loop run once "for nothing" after having IsMoving==false, then next time i got the correct DRO values with the plugin API. There is anyway a beat if the plugin loop period is 25ms and the positions updates periods is 20ms.
That will delay small movements, because i then lose 2 loop ticks per line after the Ismoving going to false.
My plugin contains a full featured GCODE interpreter of my composition. I use it in order to apply rotation, translation, scaling, and a module to have a more flexible Autoleveler (what if a probe point fall in an already drilled pocket ?, what if i want to place the probes around the engravings, and leave alone the surfaces between the engraving ?) I like Delaunay triangles !
BTW : my plugin was not AT ALL involved in the process : I loaded directly my GCODE from the Vcarve Pro 9.015 to UCCNC.

Thanks for your help.

Sebastien

This is a known issue with test version 1.2104 and should be fixed in next test version release.

Dan

Sebmay,

1.) As Dan said, the test version 1.2104 has a buffer problem which skips code randomly.
2.) No, it is not a communication problem. You can't really sniff out the UDP packets, because all packets are coded (encrypted) and decoded, so even the same command is different when sent 2 times. Packets are all encoded to make crackers' work extremely hard.
3.) Yes, there is a small delay between sending g-codes, because when you send g-code and it executes and stops then on the next code sending you expect that the coordinates and all datas are up to date to the current time and so when the stop happens the controller has to syncronise the coordinates and other datas. In other words when the stop is reported the PC software side must wait one more syncronisation cycle to make sure you have the up to date datas when you send the next g-code. The system could not work properly without waiting for this syncronisation, because then the non-coded axes in a movement would not be updated and would then roll back to an intermediate position.
There is a command CodeList to send List of commands and then there is no delay between those commands and the motions in the list are sent using look-ahead motion optimisation (if G64 is active).

Hello,

Thanks you guys for your help.

OK for everything.

Should i revert to an older release ? Which one ? (i do not use encoder, THC, i am a basic XYZ user...)

Sebastien

sebmay wrote:Hello,

Thanks you guys for your help.

OK for everything.

Should i revert to an older release ? Which one ? (i do not use encoder, THC, i am a basic XYZ user...)

Sebastien

Current version is 1.2047 and that is the only official release. With that release I have never seen anything similar to your problems. The test versions can always contain some serious bugs, so they are only suitable for test, not for production of critical parts.

Sebmay,

Yes, as Josef (A_Camera) said, the test versions are for testing purposes only, they are not adived to be used for production, especially the last few versions are strongly recommended not to, because they contain lots of new developments which all were serious risks for us for creating new bugs. We ofcourse appritiate if somebody is running the test versions though and reporting bugs to us, but only if the possible bugs cannot give too much problems and losses for the user. For production use we always advice to use the latest official release which is available on our website on the UCCNC product page: http://cncdrive.com/UCCNC.html Currently it is the version 1.2047.
A test version only go to official release when we have tested it for a long enough time and when it was out for testing for a long enough time and no bugs were reported.