tatarize
commented
2 years ago Stuttering is possible at about 100mm/s if everything is wrong. So step 2 might stutter at 200mm/s. Step 3 at 300mm/s. If step 1 and group pulses is on the stutter ceiling should be about 300mm/s. This is for step-1 with a pure gray image. If the image is either 25% or 75% gray it will go X000X000 or XXX0XXX0 respectively which has a stutter ceiling of 400mm/s. At step 2 with 25% gray the stutter ceiling is 800 mm/s which exceeds the 670 mm/s possible with the card.
@joerlane we might need your snooping at ticks powers, we need to measure the actual distance it travels between stutters in a worst case scenario. Specifically if we're in stuttering at an exact speed is it possible to know exactly the relationship between stutters at a speed. If you do rect 1in 1in 5in 5in fill gray raster --speed 150 in console and raster that exactly how long is it between stutters. And compare this to --speed 200. Pure gray should have a stutter ceiling of 104mm/s. So from a pure protocol standard what is the time between gasps for air. If we set the raster to step 1, pure gray and run it at 600mm/s exactly how long is it between stutters (these should happen nearly instantly).
We would be then able to calculate in simulation not just a warning about stuttering but potentially where it might stutter. The math here isn't too terrible. And really knowing the stutter ceiling might give the right answer. We're going pure gray at 104mm/s and hit stutters. This means we're sending DaUaDaUaDaUa at 2 characters per mil. 4094.49 mils/sec speed which means in about 1 second we process 8189 characters. This means that our stutter ceiling should be anytime processing per second must exceed 8k/s. We have characters-required-to-go-a-distance / speed > 8k/s. So if our code is set to go DzUz that's (4/510) * speed > 8k/s. So we have speed > 1020,000 mils a second or 25,908 mm/s to exceed the stutter ceiling.
Stuttering happens when speed > 8189 * (distance / chars). So 8189 / (chars/distance). So if 2/1 which is the worst we stutter at 4094.5 mils/s . At step 2 our chars/distance = 2/2 which gives us 208.0006 mm/s (2/2) or 208.
The stutter ceiling is located at: (average distance per character) 208mm/s. So if `speed > 208 (distance/character)` we will stutter. So if we're averaging 500 units of distance over 200 characters we get 208 * 500/200 which is 520mm/s as our stutter ceiling.
We can calculate this for an image if we check how often does the pixel next to this pixel equal that pixel. (That percent) * 104 gives the speed at which stuttering will occur. though this is average. You could try this in clumps or scanlines. Though we need to know the time between data accepting gasps to know how long you need to exceed this value before stuttering will occur, or rather how quickly we end up outstripping out buffer. We could probably just calculate the raw data flow with the busy commands etc. If we send more than 273 packets a second stuttering is likely to occur. Though the stuttering here is very likely to screw that up as a raw calculation since we can't really exceed that value and not stutter, so we can't exceed that value.
Sophist-UK
The idea here is that when you open the Execute Window, meerk40t analyses (using numpy) any images in the operations to be executed based on operation speed and PPI, step etc. to determine whether there will be occasional or frequent stuttering due to USB bandwidth, and if so then we give the user a warning and "expert" recommendations:
a. "Warning: You are likely to experience heavy stuttering when burning the following image elements: image1234. Use the Raster Wizard to increase the step to 2 or 3."
b. "Advice: You may experience occasional stuttering at these settings when burning the following image elements: image1234. You can reduce or eliminate these by: Turning on pulse grouping, using the Raster Wizard with a slightly higher step, increasing / reducing the operation speed to xxxmm/s, changing the PPI to 1000."