#405 Streamer wrong result.

[eslavko]

Hello...
I supose that streamer had a bug. If streamer is dissabled all values regarding status of fifo are frozen but shouldn't be. To be clear what I mean see this example:
start streamer (loadrt streamer depth=100 cfg=b) and check values with halscope

The values are
streamer.0.cur-depth = 0
streamer.0.empty = TRUE

now run halstreamer on console and enter 3 values. (1[ENTER]1[ENTER]1[ENTER])

now halscope is unchanged ie
streamer.0.cur-depth = 0
streamer.0.empty = TRUE

but supose to be
streamer.0.cur-depth = 3
streamer.0.empty = FALSE

I already fix the code but don't know how to post it. (it's feature add too)

[eslavko]

Nobody care about that?!?

[Sebastian Kuzminsky]

Hi eslavko, the behavior you described observing sounds just like the way I think it should work. Let me show you a walk-through of what i see and why i think it's right.

I'm using the current tip of the 2.6 branch, v2.6.4-22-g090bf29.

Here's what i did:

/home/seb/linuxcnc.git> halrun
halcmd: loadrt streamer depth=100 cfg=b
halcmd: show pin streamer.0.
Component Pins:
Owner   Type  Dir         Value  Name
   178  s32   OUT             0  streamer.0.curr-depth
   178  bit   OUT          TRUE  streamer.0.empty
   178  bit   IN           TRUE  streamer.0.enable
   178  bit   OUT         FALSE  streamer.0.pin.0
   178  s32   I/O             0  streamer.0.underruns

So that's streamer loaded and initialized, but not running yet.

Then in another terminal i ran halstreamer and typed this:

1
0
1
0
1

Then I looked at the streamer pins again, they are unchanged, of course, since streamer is not running yet:

halcmd: show pin streamer.0.
Component Pins:
Owner   Type  Dir         Value  Name
   178  s32   OUT             0  streamer.0.curr-depth
   178  bit   OUT          TRUE  streamer.0.empty
   178  bit   IN           TRUE  streamer.0.enable
   178  bit   OUT         FALSE  streamer.0.pin.0
   178  s32   I/O             0  streamer.0.underruns

Then i created a thread, added streamer's function to it, and started it running:

halcmd: loadrt threads name1=slow period1=100000000 fp1=1
halcmd: addf streamer.0 slow
halcmd: start
halcmd: show pin streamer.0.
Component Pins:
Owner   Type  Dir         Value  Name
   178  s32   OUT             0  streamer.0.curr-depth
   178  bit   OUT          TRUE  streamer.0.empty
   178  bit   IN           TRUE  streamer.0.enable
   178  bit   OUT          TRUE  streamer.0.pin.0
   178  s32   I/O            61  streamer.0.underruns

I can't use halscope to inspect the streamer pins through this, because halscope stops and complains if its thread is not running.

So i used "watch -n 0.1 -d halcmd show pin streamer" in another terminal instead. When I typed the "start" in halcmd above it starts streamer running, and I could see .curr-depth counting down and .pin.0 toggling just as expected. When the queue drained, .pin.0 got stuck at the last value, 1 (aka True), and .underruns started incrementing, just as expected. This is the state shown by the final 'show pin' above.

So, all's well, as far as i can see.

[Sebastian Kuzminsky]

Oh wait, do you mean that streamer's .curr-depth and .empty pins should be updated even when .enable is False? That's probably a good idea.

Do you have a patch to share?

[eslavko]

Yes.
The complete code is in feature request as I added some pins too.

[eslavko]

...And yes I mean that this pins should be updated when enable is false. On start mostly you need to wait to fill fifo and then enable it. But as is you can't see if fifo is ready without starting it.

[Sebastian Kuzminsky]

Fixed in 2.7.0-pre7.