Add parameter to PO command to allow it to be sequenced in the motion queue · Issue #186 · evil-mad/EggBot · GitHub
More Web Proxy on the site http://driver.im/
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently (2.8.1) the EBB firmware PO command is executed immediately whenever it is processed by the EBB. This may be in the middle of an already executing motion command (like SM) which may not be what is desired. It would be very helpful to be able to sequence PO commands in the queue along with other motion commands so that the timing of the pin change lines up with the other motion commands.
This can be done by adding a optional new parameter to the PO command. If this parameter is a 0, then the PO command will be executed immediately. If it is a 1, then it will be added to the motion queue and executed in turn with the other motion commands.
The text was updated successfully, but these errors were encountered:
We have ServoCMD channel on the logic analyzer set up to toggle every time through the 25KHz ISR when a Servo move command is active. So during the 250ms of the 'delay' in the sequence above, you can see that the whole time ServoCMD is toggling.
The command sequence above shows how the PO,B,3,1 command is not blocked by the two previous SP commands and instead fires in time right after the first SM command is complete (in essence).
However, by adding in an extra SP command, you CAN force the PO,B,3,1 command to wait until after the SP delay:
This is because there are effectively three motion commands that are queued up before the USB system blocks further communications. The first is the currently executing motion command, the second is the motion command in the queue, and the third is the motion command which has been received and processed by the EBB but is waiting until there is room in the motion queue before adding it to the queue.
So in the above sequence, at the point where the SP,1,250 delay begins executing, it is the currently executing command, the first SP,1 command is the command waiting in the queue, and the second SP,1 command has been processed but is waiting for the queue to become empty before it can finish processing and allow more commands to flow from the PC. Only once the delay is over can the second SP,1 be finished (put on the queue) and then the next command (PO,B,3,1) received and immediately executed.
So even on 2.8.1 and before firmware it IS possible to control the timing of BO commands with the motion queue, but it requires careful command sequencing and also requires completely stalling the USB communications.
Using the 2.8.2 or above firmware which includes the version of PO which can be put in the motion queue is a simpler solution to sequencing the PO command with other motion commands.
I am proposing that we leave this feature out of v3.0.0 EBB firmware. While it is a neat feature and would be great to have, unless there are particular use cases where this is the only way to achieve some result, I would like to leave this feature request for a future version of firmware. The primary reason is that we currently have a single byte which designates the type of command of a FIFO element. Each bit in the byte is used to indicate a different type of command - a servo move, a simple stepper motor move, a complex stepper motor move, etc. Currently (v3.0.0-a23) all eight bits are being used. If we need to add this new version of the PO command in, it will require either an expansion to a two byte value for denoting the command or a switch to a system that doesn't use bitfields. (pre v3.0.0 firmware did not used bitfields, but a handful of instructions were saved in the motion ISR by moving to the current system).
Currently (2.8.1) the EBB firmware PO command is executed immediately whenever it is processed by the EBB. This may be in the middle of an already executing motion command (like SM) which may not be what is desired. It would be very helpful to be able to sequence PO commands in the queue along with other motion commands so that the timing of the pin change lines up with the other motion commands.
This can be done by adding a optional new parameter to the PO command. If this parameter is a 0, then the PO command will be executed immediately. If it is a 1, then it will be added to the motion queue and executed in turn with the other motion commands.
The text was updated successfully, but these errors were encountered: