CRIO-style architecture for Raspberry Pi

[smithd]

  On 8/6/2016 at 7: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).

Expand  

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

 

  On 8/13/2016 at 10: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.

Expand  

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]

  On 8/14/2016 at 10:56 PM, 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).

Expand  

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 8/6/2016 at 1:33 AM, smithd said:

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

Expand  

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]

  On 8/14/2016 at 10:56 PM, smithd said:

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

Expand  

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]

  On 8/15/2016 at 10:36 AM, 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.

Expand  

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]

  On 8/15/2016 at 7:01 AM, 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.  

Expand  

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?

  On 8/15/2016 at 10:36 AM, 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.

Expand  

 

  On 8/15/2016 at 10:59 AM, 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.

Expand  

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]

  On 8/15/2016 at 4:09 PM, 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.

Expand  

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]

  On 8/15/2016 at 4:09 PM, 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.

Expand  

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]

  On 8/15/2016 at 4:09 PM, smithd said:

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

Expand  

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]

  On 8/15/2016 at 10:14 PM, 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.

Expand  

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.

  On 8/15/2016 at 5:08 PM, 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.?

Expand  

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,