search

synthetos / g2

g2core - The Next Generation
Other
622 stars 296 forks source link

Bad state after gpio input action stop #484

Closed dauriata closed 1 year ago

dauriata commented 3 years ago

With latest edge build 101.03, when triggering a gpio configured as action stop, the motion actually stops but a wrong position is reported ( updated to the target position ) Looks like we also end up in a program stop state but with the queue not flushed as a cycle start can finish the move example moving from y0 to y200 and hitting stop in the middle of move :

image

As a side note, I was expected GPIO action stop and fast stop to behave like ! feedhold, but looking at the code I see that "fast stop" is not implemented and is like "stop". And "stop" does a program stop, not just like "!" feedhold. I think it would be more useful to have a hardware input button for just feedhold rather than feedhold followed by program stop. in my opinion program stop is more a function that would be done from the higher interface used to control the job.

dauriata commented 3 years ago

Just find out that this might be same bug as #479. Although this case is reproducible.

lutorm commented 2 years ago

I would also like to be able to trigger a feed hold with a GPIO. Being able to quickly trigger a feed hold with an external button is very useful if you see something going wrong.

dauriata commented 1 year ago

After digging again this issue after a while, I came to a working solution : in edge-preview, I changed the _hold_input_handler in canonical_machine.cpp to : cm_request_feedhold(FEEDHOLD_TYPE_ACTIONS, FEEDHOLD_EXIT_CYCLE);

FEEDHOLD_TYPE_ACTIONS allows feedhold to enter secondary planner p2 where gcode model is updated with current hold position instead of keeping target position.

FEEDHOLD_EXIT_CYCLE allows to resume cycle after entering feedhold

I believe this should be the default