Skip to content

raster: do not show a running raster as disabled mid-cycle - #4684

Open
grandixximo wants to merge 1 commit into
LinuxCNC:masterfrom
grandixximo:raster-enabled-flicker
Open

grandixximo wants to merge 1 commit into
LinuxCNC:masterfrom
grandixximo:raster-enabled-flicker

Conversation

@grandixximo

Copy link
Copy Markdown
Contributor

raster's function cleared enabled at the top of every cycle and set it again in the RUN state, so a non-realtime reader polling the pin could see 0 while the raster ran. Programmer.stop() in lib/python/raster.py waits for enabled to go false, so it could return before the function had handled the stop. The next begin() then wrote its header, the stop's hal_port_clear() wiped it, and the following start() read pixel data as the header and faulted with InvalidBPP.

enabled is now written once per state and only cleared once a stop has been handled.

Found in @hdiethelm's parallel test runs (#4669). With a 2 ms delay after the old clear, tests/raster fails 2 of 3 runs; with this change it passes 4 of 4 with the delay.

The function cleared enabled at the top of every cycle and set it again
in the RUN state, so a non-realtime reader polling the pin could see 0
while the raster ran. After stop() it then saw 0 before the function had
handled the stop, wrote the next program header, and the stop's
hal_port_clear() wiped it; the next start read pixel data as the header
and faulted with InvalidBPP. Write enabled once per state instead, and
only clear it once a stop has been handled.

Found by Hannes Diethelm's parallel test runs (LinuxCNC#4669). A 2ms delay after
the old clear fails tests/raster 2 of 3; with this change it passes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant