CRIO-style architecture for Raspberry Pi

[smithd]

On 8/6/2016 at 0:16 AM, ShaunR said:

It's not portable.It is using tribal knowledge of a specific implementation of events. It is more of an abuse of events knowing they have a queue in the LabVIEW implementation so the architecture will not work in the other, true event driven language,s that I also program in (Free Pascal for example).

I don't fully understand this one. Could you clarify?

 

On 8/13/2016 at 3:55 PM, drjdpowell said:

Just an aside, but I almost never use User Events as 1:N.   I use both Events and Queues as N:1 message carriers.  Each receiver creates the communication method it prefers, preloads any initial messages, and then passes it to the sender(s).  For 1:N I use arrays of these Events/Queues.

Do you have any additional thoughts on the pros and cons of each? It seems like if you always to the N:1 case, queues are almost always better (except UIs of course).

[drjdpowell]

7 hours ago, smithd said:

Do you have any additional thoughts on the pros and cons of each? It seems like if you always to the N:1 case, queues are almost always better (except UIs of course).

If a component doesn’t have a UI (including a “debug UI”), and doesn’t use DAQmx or IMAQdx (which interface with Events), and doesn't have a reason to want multiple incoming message channels (you can’t wait on multiple different Queues like you can with Event-registrations), then I often use a Queue.   Though the benefits of using a Queue are, to my mind, very minor even in that case.  Queues are slightly faster, and have extra features that I either usually don’t really need or I actively think should never be used with interprocess messages (like enqueuing on front or flushing).  

[drjdpowell]

On August 6, 2016 at 2:33 AM, smithd said:

Seeing the command Macro::DoSomething makes me on the inside

JKI State Machine “states” are actions that are executed internally by the loop.  Unless one deliberately calls the “idle” state, “macros” of states execute in an atomic and isolated manner.  That is not the same as sending a set of messages to another process, where you have no control over what other messages are executed intermixed with yours.  

[ShaunR]

11 hours ago, smithd said:

I don't fully understand this one. Could you clarify?

Basically. If you try and use events in "Event Driven" languages, the same way you use them in LabVIEW for 1:1. Everything falls over because the assumptions about the underlying mechanisms are incorrect. I think architectures should be language agnostic.

[drjdpowell]

12 minutes ago, ShaunR said:

Basically. If you try and use events in "Event Driven" languages, the same way you use them in LabVIEW for 1:1. Everything falls over because the assumptions about the underlying mechanisms are incorrect. I think architectures should be language agnostic.

How do they manage not to (implicitly, at least) queue up "events" that affect a serial-access resource?  Real-world events do have time-ordering (pick up the ball, throw the ball, catch the ball) so I'd be surprised if it would be useful to be agnostic about this.  Other LabVIEW features, like parallel calls on non-reentrant subVIs or DVRs, are all implicitly queued.

[smithd]

9 hours ago, drjdpowell said:

JKI State Machine “states” are actions that are executed internally by the loop.  Unless one deliberately calls the “idle” state, “macros” of states execute in an atomic and isolated manner.  That is not the same as sending a set of messages to another process, where you have no control over what other messages are executed intermixed with yours.  

My problem isn't with the enqueue semantics but with the idea that an external person should ever have to queue up multiple actions. I'd prefer separating the external interface (which in this case yes would be the macros) from the internal (which might take multiple actions based on the request/event which occurred. Its not a big deal I suppose but it gets to be very confusing very fast when you mix actions to be taken with messages that are received. Thats my main complaint. My other question is, if you want these N actions to be taken synchronously without interruption, why not subVIs?

5 hours ago, ShaunR said:

Basically. If you try and use events in "Event Driven" languages, the same way you use them in LabVIEW for 1:1. Everything falls over because the assumptions about the underlying mechanisms are incorrect. I think architectures should be language agnostic.

 

5 hours ago, drjdpowell said:

How do they manage not to (implicitly, at least) queue up "events" that affect a serial-access resource?  Real-world events do have time-ordering (pick up the ball, throw the ball, catch the ball) so I'd be surprised if it would be useful to be agnostic about this.  Other LabVIEW features, like parallel calls on non-reentrant subVIs or DVRs, are all implicitly queued.

I still don't totally understand so let me come at it from the other direction which may answer drjd's question. My understanding of .net events, for example, is that they are a list of function definitions. So when you register for an event, you add your function definition to the list. When the owner generates the event, its really synchronously calling the registered function of all subscribers. However, this implementation change doesn't seem like it should matter all that much, unless you rely on the synchronous nature of events.

[ShaunR]

56 minutes ago, smithd said:

My problem isn't with the enqueue semantics but with the idea that an external person should ever have to queue up multiple actions. I'd prefer separating the external interface (which in this case yes would be the macros) from the internal (which might take multiple actions based on the request/event which occurred. Its not a big deal I suppose but it gets to be very confusing very fast when you mix actions to be taken with messages that are received. Thats my main complaint. My other question is, if you want these N actions to be taken synchronously without interruption, why not subVIs?

 

I still don't totally understand so let me come at it from the other direction which may answer drjd's question. My understanding of .net events, for example, is that they are a list of function definitions. So when you register for an event, you add your function definition to the list. When the owner generates the event, its really synchronously calling the registered function of all subscribers. However, this implementation change doesn't seem like it should matter all that much, unless you rely on the synchronous nature of events.

Well. This is do far off-topic I can't even remember the OPs questions  Maybe Hooovahh can move this and the rest to another thread.?

[drjdpowell]

21 hours ago, smithd said:

My problem isn't with the enqueue semantics but with the idea that an external person should ever have to queue up multiple actions. I'd prefer separating the external interface (which in this case yes would be the macros) from the internal (which might take multiple actions based on the request/event which occurred.

I agree, but the JKI “state queue” is not an external interface.  It cannot be accessed from outside the loop (it’s by-value, not by-ref).   Requests from external sources enter via the Event structure, which is only consulted when the “state queue” is empty.  “Macros” are multiple actions based on a single request/event. 

Added later: my talk at the 2016 eCLA Summit was on how to handle actions like a subVI, though I forgot to mention that the JKI “state queue” can be used that way.

 

Edited August 16, 2016 by drjdpowell
talk link

[drjdpowell]

15 hours ago, smithd said:

My other question is, if you want these N actions to be taken synchronously without interruption, why not subVIs?

I tend to use subVIs one layer lower down from the loop actions, as explained in this post.  One can have subVIs that represent actions of the loop itself (as the AF does, for example), but I usually find that to have (minor) disadvantages.

Edited August 16, 2016 by drjdpowell

[smithd]

4 hours ago, drjdpowell said:

I tend to use subVIs one layer lower down from the loop actions, as explained in this post.  One can have subVIs that represent actions of the loop itself (as the AF does, for example), but I don’t usually find that to have (minor) disadvantages.

Cool I'll take a look. The separation makes sense, I had forgotten it worked that way. I suppose from that direction I've recently been doing something not too far off, which is that events change the state which leads to some actions. For example it might feed in a chunk of data and change the 'desired state' value to "initialized" and then I have a lookup table which says if current state is X and desired state is Y, your next action is A. I seems preferable to me because its easy to see what actions will be taken (once you've made the lut), but it can sometimes be tough to wrap my head around what the transitions need to look like, so I can see where setting up actions more explicitly makes sense.

10 hours ago, ShaunR said:

Well. This is do far off-topic I can't even remember the OPs questions  Maybe Hooovahh can move this and the rest to another thread.?

I dunno he was asking about architecture and such. Its not that far off  

 

[dmurray]

Don't change on my account, the discussion is relevant and interesting to me. Any more questions from me will probably be distinct enough that I will start a new thread anyway,