8000 Add parameter to PO command to allow it to be sequenced in the motion queue · Issue #186 · evil-mad/EggBot · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add parameter to PO command to allow it to be sequenced in the motion queue #186

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

Open
EmbeddedMan opened this issue Oct 19, 2022 · 2 comments

Comments

@EmbeddedMan
Copy link
Contributor

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.

@EmbeddedMan
Copy link
Contributor Author

Without being able to put the PO command on the motion queue, these are the results of the following sequence

PO,B,3,0
SM,100,100,100
SP,1,250
SP,1,0
PO,B,3,1
SM,100,-100,-100

image

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:

PO,B,3,0
SM,100,100,100
SP,1,250
SP,1,0
SP,1,0
PO,B,3,1
SM,100,-100,-100

image

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.

@EmbeddedMan
Copy link
Contributor Author

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants
0