laser pausing in the middle of a straight vector cut

[Keith Winter]

One more quick question does it happen at certain times of the day, could the laser be getting too hot? When is the last time you cleaned the fans and filters?

[Lee DeRaud]

BUT-- if the bottom left Y coordinate was 18.469 instead of 18.468 like the bottom right, then the stepper would have to move one click up on the way to the bottom right corner, and it WOULD pause briefly when it does!

Uh, no. The DDA algorithm converts endpoints to a very-high-speed stream of equal-length X and Y steps. If it had to pause every time two steps in X are separated by a step in Y, those oblique lines on the sides would take about 30 seconds each to cut...they don't.

[Lee DeRaud]

I believe you but Trotec has repeatedly told me there is no memory on Trotecs and the only processors are the circuits on the control board, aka no CPU. I've gone round and round with them over it trying to figure out issues. They all stay firm to that, tech support and sales.

I use the word "processor" in its more basic sense, not to refer to something worthy of the name "CPU". It's probably just an FPGA or two. And there is memory involved, at least enough to hold a full scan line of raster data. Again, not gigabytes of RAM, just a FIFO chip in the sub-megabyte range.

[Kev Williams]

all machines are different--

I just tried this with my LS900-- I found that it totally ignores a very slight slant until I make steep enough for the stepper to add about 10 clicks spanning the approx. 2.4"... Until then, no clicks at all. How other machines react is anyone's guess! But I see it happen with my tool machines all the time..

[Rich Harman]

I believe you but Trotec has repeatedly told me there is no memory on Trotecs and the only processors are the circuits on the control board, aka no CPU.

They must be referring to the type of memory where you can download the entire job to the machine then run it independently of a computer. The machine itself absolutely must have some memory to store the incoming information and then put it to use. The incoming serial data would be stored, error checked, then sent on to some other memory location to be processed by the controller. When it is no longer of use it would be flushed to free up space for more data. The amount of data required to cut a single straight line is so small that I could not believe that it would cause the machine to pause and wait for more data to come in.

[Rich Harman]

... I found that it totally ignores a very slight slant until I make steep enough for the stepper to add about 10 clicks spanning the approx. 2.4"... Until then, no clicks at all.

Your machine is pausing 10 times to make the line??? Or are you just observing how the Y axis stepper is advancing but the laser is moving smoothly during the line?

[Keith Winter]

They must be referring to the type of memory where you can download the entire job to the machine then run it independently of a computer. The machine itself absolutely must have some memory to store the incoming information and then put it to use. The incoming serial data would be stored, error checked, then sent on to some other memory location to be processed by the controller. When it is no longer of use it would be flushed to free up space for more data. The amount of data required to cut a single straight line is so small that I could not believe that it would cause the machine to pause and wait for more data to come in.

Rich and Lee I believe you. However I've been round and round with tech support and they continually deny any ram or memory of any sort. Never try to use logic with tech support is what I've learned.

As for the OP curious about my other questions and if heat has anything to do with it?

[Lee DeRaud]

Rich and Lee I believe you. However I've been round and round with tech support and they continually deny any ram of any sort. Never try to use logic with tech support is what I've learned.

As for the OP curious about my other questions and if hear has anything to do with it?

There may not be anything on the circuit board readily identifiable (or, more to the point, replaceable) as "RAM".

But implementing a FIFO of the required size on an FPGA is trivially simple, and a FIFO is still "memory" by pretty much any definition.

[Gene Jameson]

ok I have dived a little deeper into this issue and I have spent way more time on it than a sane person should. but now it is personal. This is long and tedious but I thought I would share what I have figured out.

If you saw the video you know the issue is the pause in the middle of the last segment. Several on here have talked about the x, y servos needing this pause to accocunt for such slight movement in one of the axes. I really have problems with this explanation because we have a cnc router here that has no trouble doing simultaneous x and y movement with out missing a beat. And this is basically the explanation given by epilog. I just don't like it. Others talked about the possibility of slow down because of a lack of communication speed between the computer and the laser. I have a Universal Laser that requires the computer to be on to run a job. The Epilog machines only require the computer to send the job. Once the job is sent to the laser, the computer can be turned off and the job still runs fine. So I don't think it is an issue that involves computer power at all. So I did some more testing and this is what I found:

Test 1: I reran the problem part just like in the video to make sure it runs the part the same way with the same pause. It ran just like before with the pause in the center of the last segment.
Test 2: I drew a single hairline the same length as the one that has the pause. Sent it to the laser and it ran straight across with no hesitation.

after this is decided to double check the coordinates of the endpoints of the original line to make sure it is purely on one axis. It was. But I did notice two nodes within a few thousandths of each end point of that line segment. I felt stupid that I had not noticed these nodes before, but I re-sent the job to the laser (Test 3) and the hesitation was still there. I was kinda glad that did not fix the problem.

Next, I re-examined the line and right clicked on it and noticed the option "to line" was not grayed out and "to curve" was grayed out. This meant the segment was a curve. I had not noticed it because the adjustment arrows were so straight and I was usually too zoomed in to see the ends of them. Now I felt really stupid and changed the segment "to line". Of course, I re-sent (test 4) the job to the laser and it cut straight across with no hesitation ($#!t). The two end points of the line had been on the same y coordinate but the center or apex of that curved segment was 0.002 above that coordinate. This seems to prove the notion of such a small incremental change in the y axis causes the hesitation. This stinks, because I just don't think it needs to be this way.

Then I took the straight line segment I created in step two and added a node in the middle and ran the job (test 5). it ran without hesitation, so I know just adding the node did not create a hesitation. For test 6 I converted the segments on each side of the new node "to curves" and I nudged the center node up 0.002 to create the same geometry of the original part with one exception. it now has a node in the center. Sent it to the laser and ran it. The laser hesitated 2 times on this segment, at the center of each half of the line. This test just added further support to the encoder incremental change explanation.

For one last test, test 7, I simply double clicked on the center node to delete it. The curvature of the segment remained and I sent the job to the laser again. This time it ran the whole segment without hesitation. I don't get it. I was stating to buy into explanation that the encoder is a linear encoder that is attached to the axis. Compared to our CNC router where the encoders are on the servos themselves giving a greater density of encoder positions per linear movement of the axis. But the last test proves that is not necessarily the case. At least I can begin to use nodes and curves/lines to fix it when it happens.

[Lee DeRaud]

Next, I re-examined the line and right clicked on it and noticed the option "to line" was not grayed out and "to curve" was grayed out. This meant the segment was a curve. I had not noticed it because the adjustment arrows were so straight and I was usually too zoomed in to see the ends of them. Now I felt really stupid and changed the segment "to line". Of course, I re-sent (test 4) the job to the laser and it cut straight across with no hesitation ($#!t). The two end points of the line had been on the same y coordinate but the center or apex of that curved segment was 0.002 above that coordinate. This seems to prove the notion of such a small incremental change in the y axis causes the hesitation. This stinks, because I just don't think it needs to be this way.

Then I took the straight line segment I created in step two and added a node in the middle and ran the job (test 5). it ran without hesitation, so I know just adding the node did not create a hesitation. For test 6 I converted the segments on each side of the new node "to curves" and I nudged the center node up 0.002 to create the same geometry of the original part with one exception. it now has a node in the center. Sent it to the laser and ran it. The laser hesitated 2 times on this segment, at the center of each half of the line. This test just added further support to the encoder incremental change explanation.

For one last test, test 7, I simply double clicked on the center node to delete it. The curvature of the segment remained and I sent the job to the laser again. This time it ran the whole segment without hesitation. I don't get it. I was stating to buy into explanation that the encoder is a linear encoder that is attached to the axis. Compared to our CNC router where the encoders are on the servos themselves giving a greater density of encoder positions per linear movement of the axis. But the last test proves that is not necessarily the case. At least I can begin to use nodes and curves/lines to fix it when it happens.

[raw random speculation follows...]
The common factor in the "failed" cuts seems to be that the curve consists of two separate Bezier segments, one with control points at the start node, the other with control points at the end node. My suspicion is that the firmware gets to the end of the first segment and then has to compute all the points on the other segment (working back from the far end) to figure out where to go next. Hence the pause. This theory has the advantage that it has nothing to do with the physical motion system, which, as you noted in your last test, can handle the actual motion involved without any problem.

It might be instructive, assuming it's possible, to look at the actual job as transmitted to the machine. It appears the Epilog is working at a higher level than ULS (and presumably Trotec), decomposing curves to line segments at the laser end rather than the computer end, minimizing storage space but thus having to deal with more extensive math at burn-time. My ULS works similarly to Kev's description in post #11, except that the low-level 'plot' components are formatted (more or less) as WMF rather than HPGL. (As I recall, WMF has arc and ellipse primitives, but the ULS spool files don't use them, converting everything to straight line segments.) All the vector reordering and optimization is done in the print driver as well.

[Rich Harman]

ok I have dived a little deeper into this issue and I have spent way more time on it than a sane person should. but now it is personal. This is long and tedious but I thought I would share what I have figured out...

Thank you for diving into the issue and reporting your findings, including your own errors. :-)

Not sure how to put this without offending, but it is disappointing to me that a mainstream (expensive) laser would have such a silly problem. The only time my laser has ever paused during a line is when cutting circles at a too-fast speed. And that pause is a fraction of the length as the one you experienced. It would pause for like a tenth of a second while it adjusted for backlash at each quadrant. When cutting at reasonable speeds, no pausing is perceptible.

I wonder if you were to smart fill the original graphic, then use that to cut the shape, would it still do the pausing?

[Keith Winter]

Nothing's perfect.. I've even seen a Trotec pause maybe once or two waiting on transmission but the computer was bogged down opening a massive file. It was a split second but enough to make you think wth? That's one or two times in three years though, pretty darn rare and nothing like he's experiencing. We also experience other transmission errors from time to time such as a section of a design line being off by 1/2 or 1/4th of a millimeter when engraving. Not a lot, but enough to ruin a design. Happens maybe once in a blue moon but it does happen...

Thank you for diving into the issue and reporting your findings, including your own errors. :-)

Not sure how to put this without offending, but it is disappointing to me that a mainstream (expensive) laser would have such a silly problem. The only time my laser has ever paused during a line is when cutting circles at a too-fast speed. And that pause is a fraction of the length as the one you experienced. It would pause for like a tenth of a second while it adjusted for backlash at each quadrant. When cutting at reasonable speeds, no pausing is perceptible.

I wonder if you were to smart fill the original graphic, then use that to cut the shape, would it still do the pausing?

[Gene Jameson]

Thank you for diving into the issue and reporting your findings, including your own errors. :-)

Not sure how to put this without offending, but it is disappointing to me that a mainstream (expensive) laser would have such a silly problem. The only time my laser has ever paused during a line is when cutting circles at a too-fast speed. And that pause is a fraction of the length as the one you experienced. It would pause for like a tenth of a second while it adjusted for backlash at each quadrant. When cutting at reasonable speeds, no pausing is perceptible.

I wonder if you were to smart fill the original graphic, then use that to cut the shape, would it still do the pausing?

I agree, it is not a huge deal but it is silly and I find the inconsistency to be annoying. My ULS 60 watt never shows any of these issues. While I am working at trying to troubleshoot problems like this the Universal is working it a$$ of and not complaining. I do find the epilog machines to be more robust in their construction, but it is hard to beat the ULS in my shop. But i am getting off topic and I am sure that can of worms has been opened many times.