Halsampler output buffer behaviour
03 May 2023 05:38 #270540
by dberndt
Halsampler output buffer behaviour was created by dberndt
I've been playing with capturing some force (from a loadcell) and position (from halui) data and streaming it to various devices. A sort of low sample/second "realtime" display, and a higher sample count streamed to database.
When using tools like python's subprocess.popen to interact with halsampler I found a challenge in that the buffer behaviour changes when fd is not stdout. Which causes output to stack up in the buffer before it's written to the "file" that is really my popen object. This is quite annoying at low data rates, because the time to fill the buffer can be quite a few seconds and then a burst of data comes through, not very good for the low sample "realtime" display I mentioned above.
I suppose I could have probably gotten around this by convincing halsampler that it was really writing to stdout by using shell mode or some other of the many popen options, but I didn't...
I also imagine there would have been some way to manipulate the system/python/whatever so that the bufferes were smaller. Didn't look into that really either.
Instead I recompiled sampler_usr with a flush after every line of output.
github.com/LinuxCNC/linuxcnc/blob/master...onents/sampler_usr.c line 223 becomes something like:
I'm not sure if this causes a real throughput issue at higher speeds, but for my use the halsampler looking more like a line by line stream was quite useful and figuring out why it wasn't "streaming" in my python code was challenging. Should a change such as this or a flag/switch that does the same be considered in future?
It's been a long time since I did any C fd and io work like this, so my fix presented above might be far from ideal. I'm open to any other solutions that provide the same modified behaviour.
When using tools like python's subprocess.popen to interact with halsampler I found a challenge in that the buffer behaviour changes when fd is not stdout. Which causes output to stack up in the buffer before it's written to the "file" that is really my popen object. This is quite annoying at low data rates, because the time to fill the buffer can be quite a few seconds and then a burst of data comes through, not very good for the low sample "realtime" display I mentioned above.
I suppose I could have probably gotten around this by convincing halsampler that it was really writing to stdout by using shell mode or some other of the many popen options, but I didn't...
I also imagine there would have been some way to manipulate the system/python/whatever so that the bufferes were smaller. Didn't look into that really either.
Instead I recompiled sampler_usr with a flush after every line of output.
github.com/LinuxCNC/linuxcnc/blob/master...onents/sampler_usr.c line 223 becomes something like:
printf ( "\n" );
fflush(stdout)
I'm not sure if this causes a real throughput issue at higher speeds, but for my use the halsampler looking more like a line by line stream was quite useful and figuring out why it wasn't "streaming" in my python code was challenging. Should a change such as this or a flag/switch that does the same be considered in future?
It's been a long time since I did any C fd and io work like this, so my fix presented above might be far from ideal. I'm open to any other solutions that provide the same modified behaviour.
The following user(s) said Thank You: Aciera
Please Log in or Create an account to join the conversation.
Time to create page: 0.092 seconds