Also, the transfer speed between PC and Smoothie is limited and it is proportional to feed and pixel resolution (=laser diameter). If you set laser diameter to 0.1mm for example, then you would be limited to less than 100mm/s. With 0.2mm laser diameter, you could reach twice this feed.
Join Pixels help to reduce the transfer volume by combining mutliple pixels with same power in one command.
if you ‘Print’ twice the same image, does it “break” at the same point ?
@Alex_Krause interesting that the specs on these machines is 300mm/sec, I think.
@cprezzi this could take us down a rat hole but isn’t the incoming stream isolated (buffered) from the machines movement?
I can see how average speed can be effected by a slow down in input but isn’t a movement buffered and then marked?
I imagined that if there was inadequate input data the head pauses waits for data and then continues. I can also imagine that if the input cannot keep up with the movement then pauses cause the mechs to do a lot of start-stops and that could excite a resonance or exaggerate something like loose belts.
My point being that the input stream throughput shouldn’t be the source of missteps or mis-positioning should it?
BTW I have a similar but not as severe problem with my machine. I created the test pattern to hunt down what I assumed to be a mechanical problem with the belts or some other overshoot etc.
@tyler_hallberg can you take a picture that shows the left and right side of the image? It would be useful to know if both edges are shifting or just one. This would point to a scan positioning problem or a reversal problem.
@tyler_hallberg @Chris_Sader if possible I would measure the 24V voltage and current. [I am assuming your are using the LPS 24V].
I wonder if the LPS 24V cannot handle high speed and peak stepper currents. Subsequently stepper power is reduced slightly during fast and high load moves.
As @Alex_Krause suggested the LPS 24V is rated at 1 amp and I am pretty sure that voltage is only used for motors in the NANO whereas the logic is powered from the 1A LPS 5V.
Like others I am guessing…
@donkjr Right, there is a planner queue in the firmware that “caches” the next few commands. By default, this is 32 moves on smoothieware (or 16 on grbl). With 0.1mm pixel size, this is 3.2mm only! But the communication still has to deliver enough data in average for the selected feed. At 100mm/s and 0.1mm/Pixel, this is 1000 G1 moves per second!
I don’t think that the transfer limitation could result in lost stepps!
I just explained that because @tyler_hallberg wrote he used a feed of 100-400mm/s.
@cprezzi Ah I get it …thanks.
@StephaneBUISSON not on mine. Luckily I got through a whole batch of 6 sided dice (so six jobs) without it happening last night
I had this problem right of the bat. I took apart the X gantry to get to the tension bracket. What I found was the belt slipping and grinding away on the tension wheel. This was caused by a metal burr in the bracket that the tensioner wheel screw shaft attaches the wheel too. Tensioning the bracket according to the posts was actually digging the plastic tensions wheel into the burr causing it to stop or grind the wheel and belts. To over come this I went another route. I took a metal toothed wheel that matched the belt teeth, and moved the bearing from the plastic tension wheel to it. I cleaned the burr on the bracket and reassembled the tension wheel onto the bracket and put the x gantray back together. This looks like a manufacturing defect that may be plauging a lot of people seeing drift in their cutting. I also used a medium thread lock on the tension wheel shaft nuts. And, put a drop of light machine oil on the bearing inside. Hope this helps.