Fix the information returned by /api/version - #5332
Open
CiaranG wants to merge 545 commits into
Open
Conversation
subrepo: subdir: "lib/Prusa-Error-Codes" merged: "d64eb1056d" upstream: origin: "git@github.com:prusa3d/Prusa-Error-Codes.git" branch: "master" commit: "d64eb1056d" git-subrepo: version: "0.4.9" origin: "???" commit: "???"
As these happen fast & outside of the print, the motor may skip, but that's OK. Don't report as filament stuck (because likely it isn't). BFW-7545
And proceed with the test anyway. BFW-7542.
Rework the ADC FS logic to get rid of the fixed FS span. BFW-5338
Not using fs_span, get rid of it BFW-5338
I will be adding REF_INS in the next commit BFW-5338
It is no longer relevant to the config store. The CalibrateInserted is now a bit mesy, but I intend to rework the whole calibration in the upcoming PR, so I would keep it this way for now. BFW-5338
The selftest expects the fsensor to report HasFilament/NoFilament right after nins calibration is done, even though ins calibration is not yet done. This forced me to reintroduce filament sensor span just for that situation. Temporary solution till the new selftest comes. BFW-5338
subrepo: subdir: "lib/Prusa-Error-Codes" merged: "a0138327b4" upstream: origin: "git@github.com:prusa3d/Prusa-Error-Codes.git" branch: "master" commit: "a0138327b4" git-subrepo: version: "0.4.9" origin: "???" commit: "???"
BFW-7465 BFW-7547
…ing frequency) BFW-7413
BFW-7413
Add alignment_issue screen Adjust finish screen Edit texts disable motors when appropriate BFW-7413
If we don't segment them, emergency_stop cannot interrupt it, and we end up with a BSOD. BFW-7544
The M18 called with 0 was meant to set the stepper timeout do "disabled", not to set interval to 0 (which had weird side effects, like the printer not moving in dock calibration). BFW-7993.
When the planner finishes recalculation of speeds, notify the MoveISR that it may take another move(s) from there, they are fresh. No need to wait up to 1ms. BFW-7873.
To prevent move ISR starvation. It's hopefully fine, as that one does only bit of computations and doesn't wait on any peripherals or other tasks. BFW-7873.
This prevents starving events in phase stepping in case of high-speed curved moves, where the input shaper produces insane amounts of very very tiny micro moves. This in turn prevents layer shifts. This is probably just a workaround. The input shaper (running in the stepper interrupt, which is very high priority) should have enough time to refill the buffers. It seems that once it fills the output buffer, it doesn't get called again when it empties and instead waits for some other event on other axis (Z or E). This needs some further investigation, but for now this seems to improve the situation significantly. The new value of 128 was discovered by experimental means with a very hard-core layer shift reproducer, so it should be safe for any practical means. BFW-7873.
When running low on data in precise stepper or phase stepping, try to wake up the move interrupt early, to refill. * We hope there are some move segments cached to be processed even in case planner is currently blocking more of them. * We hope there will be enough time or that the stall will be as short as possible if there isn't; certainly better situation than waiting for up to a whole 1ms. * Remove the critical section from the planner side again - even if the moves are blocked, we may be able to do the refill from the cached data. Remove it with just an atomic flag so the move ISR will just skip looking there while it's being updated. BFW-7936, BFW-7873.
With the running-dry wakeup, we can lower the queues again a bit - we don't necessarily have to survive for a whole 1ms in that case. BFW-7936, BFW-7873.
Instead of limiting the amount of segments processed to at most 1 per 1ms (or one call now), process as much as possible. We've observed segments with shorter times than 1ms. Even when we have the wakeup on running dry, it's better to keep the buffers full and have smaller amount of the interrupt calls for performance. BFW-7873.
Instead of guessing if taking moves out of planner made progress indirectly, just return it from the function. This is a slight optimization of the move_isr loop. BFW-7873.
Recent changes made it overflow from time to time (they either made the stack of some interrupt function larger or the chance of multiple interrupt stacking on each other got higher). Trying to add 100 bytes (+alignment), as we don't have a direct way to measure how much we need. BFW-7873.
Cherry-pick with added C1 values Co-Authored-By: Dano Pernis <danopernis@gmail.com> Co-Authored-By: Ondřej Veselý <o.vesely42@gmail.com> BFW-7395 BFW-8021
BFW-7395 BFW-8021
BFW-7395 BFW-8021
BFW-7395 BFW-8021
More granular tracking of the printer's setup progress. And display only the ones missing when printer si selectively factory reset. BFW-7867
BFW-7945
BFW-8021
Crash recovery was hard-switching to Resuming_Begin print state, which: - Did not trigger media_prefetch_call() - Skipped the resuming buffering phase. Using print_resume unifies the functionality and print_resume makes sure that all necessary steps are done. BFW-8082
As per the FIXME comment in the code, it currently returns the lwIP stack version number, which is of no use to anybody. On the Raspberry Pi PrusaLink returns a "server" field with the standalone PrusaLink version and a "firmware" field with the actual firmware version. And the "firmware" field appears to be required by the spec. This commit returns "firmware" as the firmware version, in line with that, and also corrects "server" to be the same, since "PrusaLink" is embedded here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As per the FIXME comment in the code, it currently returns the lwIP stack version number, which is of no use to anybody.
On the Raspberry Pi PrusaLink returns a "server" field with the standalone PrusaLink version and a "firmware" field with the actual firmware version. And the "firmware" field appears to be required by the spec.
This commit returns "firmware" as the firmware version, in line with that, and also corrects "server" to be the same, since "PrusaLink" is embedded here.