Continuous Wave Program Concept #605
Comments
|
Have you looked at the ‘wave_create_and_pad’ api? This api addresses some
the concerns you raise.
…On Mon, May 27, 2024 at 2:12 AM SoundsSerious ***@***.***> wrote:
I have been finding this library quite useful, but have have discovered
some issues driving stepper motors similar to #126
<#126>, #382
<#382>, and #146
<#146>
Each of these issues seems to demand maintaining a continuous set of
pulses, however the issue being its challenging to orchestrate wave
deletion / waiting leads to issues with memory available.
Since this is a pretty common use case for things like CNC or other
hardware where the PWM concepts dont work due to resolution / rate issues,
and waves has issues pausing between wave TX.
I had an idea that a "Wave Program" could be implemented that would
control a single pin with a defined on/off time, and where an internal
counter could handle long pauses over a second or over the buffer size.
This I think would be relatively simple to implement and would put another
tool in the toolbox for pigpio.
Waves is a really cool feature but involves some difficult concepts such
as interleaving the pin programs. I believe the delete part is an issue. I
think there should be a simple solution to this important problem where any
failure of the waves program can lead to saftey risks (mechatronic issues
like crashing for example).
Curious to hear your thoughts, or any additional ideas related to this
topic.
—
Reply to this email directly, view it on GitHub
<#605>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHDHTDCCXPX42DTI5P6DV3DZEJ3ATAVCNFSM6AAAAABIKGW6SKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGMYTOOJZHA2DMNA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Thanks for the reply, I think part of my issue is that I haven't exactly got the mental model right for waves. I have been manually padding waves to account for timing. Is that similar? My solution is currently more focused on preventing over-submission and buffer errors that disrupt functionality. I still feel like I'm fighting the API to get this to work in a clean / reliable way. I think there's an interesting space for a 3rd way here between PWM and the highly cool / customizable waves feature. Also I am using this library which has let me approach timing and workload a bit differently than the synchronious approach here. https://github.com/spthm/asyncpio |
|
The "padding" concept for creating waves was implemented to fix the buffer sizes used for the wave resources. This avoids fragmentation and the problem associated with deleting one wave and replacing it with a wave of a different dimension. So, in its simplest form (and the only way I've used it) when you pad a wave at 50% you have a double buffer scenario. You create any arbitrary wave, using wave chaining, looping etc. Assuming your wave playback time is long, as in tens or hundreds of msec, you have ample time to create the next portion of your 'continuous wave' then synchronize it to the currently playing wave. Now you simply monitor the wave id status to know when a wave has completed, deleted it and begin initializing the next segment of your wave. You can dimension each portion of the wave (total length, number and width of pulses) as you wish, it's only the memory resources that have been fixed. |
|
Hmm thats interesting. That would certainly help solve the buffer issue. I'll give that a shot! In my application I have three sets of async tasks generating and creating waves at the same time, where I expect python timing resolution to be between 1-5ms, and am batching groups of waves at the same time. I think this is probably not the intended usage as I think part of my problem orchestrating these multiple wave "tasks" make checking the current wave id less reliable as it isn't clear which one is currently being transmitted although most probably are. I realize this may not be the intended application here but I do think its incredibly useful as I can do things that are significantly blocking like TCP networking / waiting on subprocesses ect while maintaining 1Mhz resolution GPIO thanks to pigpio :). It also helps keep code more manageable inside small async task functions. Perhaps this is more of a fork level of idea but I think having a stateful "pin program" would help organize the bookkeeping for multiple pin signals, which it sounds like is challenging mixing waves. Perhaps the current wave API is the low level interface and a simplistic / stateful interface exists to handle single pin orchestration which is probably 95% of GPIO use cases as opposed to multiple-pin orchestration for I2C, SPI ect. Putting single pin orchestration as a higher level concept also solves these timing issues since the pigpio process can always perfectly orchestrate itself. |
|
This library is presently in maintenance mode. I can help you with questions on the APIs but will not be making significant enhancements. |
|
Understood, thanks for helping me with my understanding! I'll leave it up to you to close the issue or keep it open |
I have been finding this library quite useful, but have have discovered some issues driving stepper motors similar to #126, #382, and #146
Each of these issues seems to demand maintaining a continuous set of pulses, however the issue being its challenging to orchestrate wave deletion / waiting leads to issues with memory available.
Since this is a pretty common use case for things like CNC or other hardware where the PWM concepts dont work due to resolution / rate issues, and waves has issues pausing between wave TX.
I had an idea that a "Wave Program" could be implemented that would control a single pin with a defined on/off time, and where an internal counter could handle long pauses over a second or over the buffer size. This I think would be relatively simple to implement and would put another tool in the toolbox for pigpio. This program's rates / on-off times could be updated, paused or stopped. Applying another signal to the pin would override the functionality the same as other concepts in this library.
Waves is a really cool feature but involves some difficult concepts such as interleaving the pin programs. I believe the delete part is an issue as you've mentioned @joan2937. I think there should be a simple solution to this important problem where any failure of the waves program can lead to saftey risks (mechatronic issues like crashing for example).
Curious to hear your thoughts, or any additional ideas related to this topic.
The text was updated successfully, but these errors were encountered: