Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce the printing time by a 20% (down to 25 minutes... 30% and 21 minutes with an experimental option) #18

Open
wants to merge 49 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@Retropotenza
Copy link

commented Sep 10, 2017

  • Refactored the position updates and state management, to simplify the development of new printing patterns
  • Added a zig-zag printing pattern that avoid issuing stop commands (well only one every two lines remains)
  • We can print a line with 321 commands (vs the previous 640), but now we need to send 5 USB request per command (vs the previous 3), to avoid pixel skipping
  • The overall printing time per pixel went down to 40 ms, from 48 ms

LightningStalker and others added some commits Aug 18, 2017

Update README.md
Changed others to other
Update README.md
Fixed some of my grammar and language
Merge pull request #1 from LightningStalker/leds-buzzer
Onboard LED(s) flash and optional buzzer sounds after printing to notify the user
Merge pull request #2 from LightningStalker/leds-buzzer
LED and buzzer function now optional
Update Joystick.c
Added back the missing newline at the end
Printing speedup
* Added bidirectional printing
* Removed time delays on echoes, there is no need for them
* Minimized the number of echoes (at least 3 needed)
* Verified and cleaned up USB control request and HID task (only the HID task is needed, return codes in it for endpoint reading and writing now are checked)
Fixed an issue with final vertical position
* Moving to done when ypos reach 119
* Inking the last dot before switching to done
* Updating the test pattern to better check on bounduaries
Merge pull request #2 from Retropotenza/printing-speedup
Fixed an issue with final vertical position
Merge pull request #3 from LightningStalker/master
Whitespace, wording in README.md
Merge pull request #9 from Retropotenza/master
Pulling Python script updates
Replace missing `obj` directory
I don't know how this disappeared, but looks like it's gone from all the repos?

LightningStalker and others added some commits Sep 1, 2017

Merge pull request #5 from shinyquagsire23/master
Printing speedup (from an hour to half an hour) (#17)
Refactoring to simplify the testing of different printing patterns an…
…d timing

- Moved position updates outside state management
- Added a check on position before inking
- Simplified MOVE and STOP states
- SYNC states commads now are controlled over an explicit time value (relaying on the endpoint USB polling interval)
- Set the endpoint USB polling interval to 8 ms
Added a zig-zag printing pattern
- Print two lines in parallel, avoiding to stop at each move (actually doing just one stop, and a double move)
- This halves the number of commands needed for printing
- But we had to send 5 reports instead of 3 (thus we only reduced the printing time of one dot from 48 ms to 40 ms)
- Going down to 32 ms will skip some pixels (is the 1/30 s screen refresh rate the limit here?)
Merge pull request #6 from Retropotenza/zigzag
Reduce the printing time by a 20% (down to 25 minutes)
@Retropotenza

This comment has been minimized.

Copy link
Author

commented Sep 10, 2017

In theory this should have gone twice as fast (15 minutes to print), but any setting that goes below 33 ms/pixel (33.333 ms/pixel... corresponds to a 30 fps) seems to create pixel skipping.

Now we are at 40 ms/pixel, with 5 USB reports sent for each printing command (8 ms each).

I tried to go to 33 ms/pixel, setting the USB polling frequency to 11 ms, with 2 echo (3 reports). The device continue to generate a 8 ms polling :-(... Indeed it looks that only multiple of 8 ms polling frequency at the end are generated, whatever setting is tried.

Retropotenza and others added some commits Sep 10, 2017

Update to the makefile
Needed to enable the ZIG_ZAG_PRINTING flag
Merge pull request #7 from LightningStalker/master
Correct typographical errors in `Joystick.c`
Optimized printing pattern
- Simplifies the tests inside the pattern
- Allows to control the direction just by checking ypos (simplifying state managment)
- Moving back the DONE test in state management
Synched to 30 fps
- While printing, injecting a USB report (8 ms) every 6 commands (4 USB reports and 32 ms each)
- This align the 6 commands to 6 video frames (200 ms)
- Stripped out all tests that are not strictly necessary (the timing is tight, better to avoid any risk)
- Removed the while on Endpoint_*_Stream_LE() (we send anyways multiple USB reports for each command, the while ther just add a risk on timing that is better to avoid)

@Retropotenza Retropotenza changed the title Reduce the printing time by a 20% (down to 25 minutes) Reduce the printing time by a 30% (down to 21 minutes) Sep 12, 2017

@Retropotenza

This comment has been minimized.

Copy link
Author

commented Sep 12, 2017

I found a way to reach 30 fps (almost) while printing: injecting an additional "echo" USB report (8 ms) every 6 commands (each doing 3 "echo", lasting 4 USB reports and 32 ms). This align the 6 commands to 200 ms, equal to 6 video frames.

I had to change (again) the printing pattern, simplifying the tests in it (the previous one didn't work well in my initial tests). I stripped away all the unnecessary tests, to reduce as much as possible any eventual timing risks.

This "synched" mode is currently enable by default by a #define, but we may leave it disabled (the new printing pattern by itself is safer, and anyways prints in 25 minutes).

@LightningStalker

This comment has been minimized.

Copy link

commented Sep 12, 2017

I was thinking about some ways to further speed up printing. For instance skipping blank lines and counting to see if there are more black pixels than white and if so using a thick pen to color everything black and then the small eraser to print white pixels, types of things a human sketcher would do instinctively

@Retropotenza

This comment has been minimized.

Copy link
Author

commented Sep 12, 2017

The challenge here is to understand how the acceleration triggered by consecutive moves in the same direction works. I initially do some quick test, and was not something trivial to measure.

On a second thought, at that time I didn't yet understood the timing relationships between video refresh and USB reports. If N moves in the same direction generate always a skip on M pixel, a kind of run length encoding printing could be done.

The low hanging fruit is "positive" printing, that could accelerate handmade drawings (but mot much dither images).

Retropotenza added some commits Sep 12, 2017

Turn off SYNC_TO_30_FPS by default
- It works most of the time, but sometimes breaks
- We need to add another syncronization stage at the beginnign, to align the ready to receive and send of the USB report stream (the frequency perfectly match, but we may have a random offset)

@Retropotenza Retropotenza changed the title Reduce the printing time by a 30% (down to 21 minutes) Reduce the printing time by a 20% (down to 25 minutes... 30% and 21 minutes with an experimental option) Sep 17, 2017

@Retropotenza

This comment has been minimized.

Copy link
Author

commented Sep 17, 2017

I did more test, and I found that sometimes the printing pattern breaks, if SYNC_TO_30_FPS is set. Is not just a pixel skew, it completely skew all the USB report stream. I believe that the frequency completely match, but that there is a random offset that in these conditions could generate this issue.
We need an additional stage at the beginning. The idea (if feasible) is to check the time that pass between when the device is ready to send a report, and when the Switch is ready to receive it, and insert some spin loops until they are below a working threshold.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.