kewakl (Customer) asked a question.
In my testing of PAC's new MQTT feature, I determined that I did not want a FIFO/LIFO or a ShiftRotateArray (SHA) buffer. I built a ring/circular buffer (Proof of Concept) that does what I think that I need.
FIFO/LIFO has data visibility limitations, SHA may impact whether either READ process or WRITE process has unfettered access to the buffer/data location. The ring buffer should not have either limitation.
For MQTT, I would need to change the buffer datatype to STRING, but it was easier to get seemingly-random-looking data (Total Scan Count 1) using S32 datatype.
As is, this buffer project provides a data/WRITE pump and a READ pump. READ and WRITE actions can be individual enabled. This allows for testing and visualization of the buffering capabilities.
Almost everything about the buffer was derived from -- https://en.wikipedia.org/wiki/Circular_buffer
Feel free to test, use, comment, fix/update/repost.
If you find this useful, please comment.
Thanks
I have not tested it out due to the simulator currently not working in this version of the software. It looks good. This is similar to a post I did with the Click PLC and a warehouse stacking example.
https://accautomation.ca/click-plc-easyplc-warehouse-stacker-example/
Regards,
Garry
https://accautomation.ca/series/easyplc-software-suite/
Garry, have you entertained the idea of combining the pointer math and the wraparound logic into one math?
Something like ( DS50 % {bufSize} ) + {bufOrigin} ) --> DS50
where {bufSize} and {bufOrigin} are DS registers or hard-coded values.
You may have coded as is for readability. Granted, it is a long and info-dense post, so I have not carefully read all of it! :) I did look at the pretty pictures.
Yes, I did code it for readability. Also, the indirect pointers in the Click can only be done with the copy command. This forces you into breaking out the logic more.
The logic in the BRX or Productivity would be more efficient but this still works.
Garry