passing enum values via rt fifo

[sciu]

Hi wiebe

Thanks a lot for your suggestions. I defined the rt FIFO constant again in the "init" process and also the corresponding typedef - and (for some unknown reason) it works much better right now. The only Thing that is still a bit strange is the fact that the initial command is not transferred to the data logging VI - that means that I have to press the "Transfer"-button several times in order to get the command executed. After that the Transmission of the following commands works fine. Maybe it might be like that because of what you've mentioned regarding the loss of values or the stall of the write Loop...

[wiebe@CARYA]

I don't thing you showed the write end of the queue. If you continuously write to it in a loop, and the size is 1 element, changes are elements get lost. I think you would need to use a lossy enqueuer for that to actually work, a normal enqueuer would wait until there is space. That is so for normal queues, I'm not sure if it works like that for RT queue's since it would seriously damage deterministic execution.

We're getting to see the code peace by peace, but I thing we can rule out the enums as the problem?

[sciu]

Well, regarding the use of a lossy enqueuer: I just have the regular enqueuer of the rt FIFO palette on hand. There is no other enqueuer in LW as far as I know...

I think you're right - the enums aren't the problem.

[crossrulz]

---

@sciu wrote:

Well, regarding the use of a lossy enqueuer: I just have the regular enqueuer of the rt FIFO palette on hand.

---

Well, the RT FIFO Write defaults to a timeout of 0.  So if you are trying to add another command before the previous one was read, that command will be lost.  If you only care about the latest command, use a Notifier.  If you need every command processed, then you need to increase your FIFO's buffer size.

[wiebe@CARYA]

---

@crossrulz wrote:

---

@sciu wrote:

Well, regarding the use of a lossy enqueuer: I just have the regular enqueuer of the rt FIFO palette on hand.

---

Well, the RT FIFO Write defaults to a timeout of 0.  So if you are trying to add another command before the previous one was read, that command will be lost.  If you only care about the latest command, use a Notifier.  If you need every command processed, then you need to increase your FIFO's buffer size.

---

Increase the buffer size, and you might want limit the items you send as well. For instance, if there is an "idle" item in the enum, there is no need to send it every iteration, since the consumer loop will not do anything anyway (presumably). If it does, it might as well use the queue timeout to trigger the idle state.

Even if you make the queue larger, you still need to read it faster then you write...

[sciu]

Hi both of you

Thanks a lot for your suggestions. I've tried to increase the buffer size and also to adjust the timeout time. To be honest, I'm performing another solution (in parallel) where I simply Transfer the analoge data from the target via rt FIFO to the host-VI. Since a very high number of samples per second is not crutial (for the logging) I just had to adjust the Loop rate of the "RT to UI"-VI where all data and states are transferred to the host. That works fine so far.

In other words: the logging will be performed now on the host and not on the targed anymore. Another advantage is the fact that the data will be stored on the host computer and not on the target controller.

Maybe it's a "dirty" solution...but nevertheless I'll try to improve the Performance of the "enum-transfer" via rt FIFO in my program.

Another question: does anyone know how to rename channels in a "write-to-measurement-file"-express VI?

Thanks a lot