Hardware Abstraction, Interrupts, and AF

[kwkengineer]

I have a hardware abstraction architecture that is built on AF, and I've recently run into an issue I would like to discuss.

The architecture consists of one Actor for each hardware interface, let’s call it a Transporter. The parent Transporter contains dynamic dispatch methods for Open, Read, Write, Close.  Children of this class contain the device specific functions.  All of this has worked great until….

Consider a full duplex serial port that must transmit and receive at the same time.  In addition data must be received (at the host), timestamped, and passed on for processing in less than one millisecond.  Typical mechanisms I’ve used like polling for elements in a FIFO or checking for an IRQ are not sufficient for this scenario.

My solution:  The Transporter now can launch a nested Actor specifically for reading data.  It has one method.  Wait Forever for IRQ (i.e. it uses the Wait for IRQ with a -1).  It also contains the dynamic dispatch methods to read and process the data when the IRQ asserts.  This solution was also fantastic until… I have three Transporters running on a dual-core cRIO.  LabVIEW initially allocates one clone per processor on the machine.  I have 3 simultaneous calls to Wait Forever for IRQ.  I expected LabVIEW to create the 3rd clone on demand, but I don’t see that happening.  Everything is awesome, until I enable the 3 Transporter.  Any two work perfectly.

Is there a way to force preallocation of the clones?  The execution property is set to preallocate, but does it really preallocate actor methods when you instantiate an actor?

Given the scenario does anyone see a better way?

Wouldn’t it be nice to assign a callback vi to an IRQ Number?  That would solve my problem.

Many thanks, Kevin

[drjdpowell]

Are you sure it is the clone that is the issue?   I've never heard of a failure to create a new clone.  Could something in the clone require a separate core.

[drjdpowell]

From the "Wait on IRQ" documentation, it mentions that each call consumes a thread.

[kwkengineer]

Ah Dang, you're right.  I spaced on that one.  Now I need a new solution because the dynamic dispatch methods can't be in different execution systems.

[drjdpowell]

But they can call subVIs in different execution systems.

[AristosQueue (NI)]

drjdpowell wrote:

But they can call subVIs in different execution systems.

I'm not sure that's going to help.

You only have a dual core machine. To do two truely parallel operations, aren't you going to need a third core?

[kwkengineer]

The subvi idea is working for me because true parallelism was not my objective.  My RT app just needed to execute a Receive Data routine when the FPGA sets the IRQ, without polling it. 

It actually surprised me that the Wait For IRQ method was limited by qty of core/execution system.  I seem to remember in my time Before LabVIEW, I could write any number of Interrupt Service Routines in embedded systems and the OS handled all the time slicing. 

[AristosQueue (NI)]

Glad you have a solution that works.