LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Does FPGA front panel Boolean mechanical action matter to control actions from an RT host?

Solved!
Go to solution

When an RT host controls an embedded FPGA VI through Booleans on the front panel of the FPGA VI, does it matter which mechanical action setting is used by the front panels Booleans?  For example, do they all just act like "Switch when pressed" or do the "Latch when pressed" act as one-shots?

0 Kudos
Message 1 of 12
(4,566 Views)

From my experience the mechanical action of the booleans act as expected even in the FPGA VI. Are you seeing something different happen or some strange behavior?

dK
0 Kudos
Message 2 of 12
(4,532 Views)

I've done some work to verify this in the past... Just thought I'd post my conclusions and supporting evidence here.

 

Latch Until Released:

LUR.PNG

Latch When Released:

LWR.PNG

Latch When Pressed:

LWP.PNG

Switch Until Released:

SUR.PNG

Switch When Released:

SWR.PNG

Switch When Pressed:

SWP.PNG

 

 

So, it looks like all of the "Latch" behaviors are exactly the same, and all of the "Switch" Behaviors are exactly the same. This is different than the LabVIEW Core implementation, and we have a bug report filed to document it as such. To summarize:

all 'Latch' mechanical actions will pulse high for one clock cycle, and all 'Switch' mechanical actions will remain high until pulled low. The timing diagrams are from ISIM.

Cheers!

TJ G
Message 3 of 12
(4,519 Views)

T-REX$,

The images in your post are not showing up for me.  I've tried both Firefox, Chrome and IE using home and work computers and all the links are just not accessible.  The links look rather odd too: http://nitalk.natinst.com/servlet/JiveServlet/showImage/2-200051-81569/LUR.PNG

 

djDannyK,

I asked the question prior to investigation of the behavior because I thought there might possibly be a difference in behavior from how I've used Booleans (my experiences) between an upper-level VI and a more subservient VI running as part of the same process tree. If the VIs share the same single-threaded process tree, then I don't think it matters what type of Boolean is used on a subVI's front panel as the subVI's execution is always in lock step with the calling VI and its front-panel Booleans will always be freshly set to the values desired by the calling VI when the subVI executes. But in the case like an RT host using a much faster FPGA routine that executes asynchronously, I can easily see that it might matter what type of Boolean is used because the host may only set it once for every thousand or so times that the FPGA reads it. 

0 Kudos
Message 4 of 12
(4,498 Views)

WNM,

 

Ironically, your user icon doesn't show up.  Just as a red X.  The path to your logo is http://forums.lavausergroup.org/style_avatars/Misc1/avatar10.gif, which apparently doesn't exist any more.

0 Kudos
Message 5 of 12
(4,481 Views)

Lets try that again then...

 

I've done some work to verify this in the past... Just thought I'd post my conclusions and supporting evidence here.

 

Latch Until Released:

LUR.PNG

 

Latch When Released:

LWR.PNG

 

Latch When Pressed:

LWP.PNG

 

Switch Until Released:

SUR.PNG

 

Switch When Released:

SWR.PNG

 

Switch When Pressed:

SWP.PNG

 

 

So, it looks like all of the "Latch" behaviors are exactly the same, and all of the "Switch" Behaviors are exactly the same. This is different than the LabVIEW Core implementation, and we have a bug report filed to document it as such. To summarize:

all 'Latch' mechanical actions will pulse high for one clock cycle, and all 'Switch' mechanical actions will remain high until pulled low. The timing diagrams are from ISIM.

Cheers!

TJ G
Message 6 of 12
(4,455 Views)

Lets try that one more time please??

 

  • all of the "Latch" behaviors are exactly the same
  • all of the "Switch" Behaviors are exactly the same
  • This is different than the LabVIEW Core??? 

What is different?- they are either exactly the same or they aren't. (I work with boolean conditions now and then so these statements confuse me)


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 12
(4,443 Views)

All of the latch behaviors are exactly the same on the FPGA, i.e. once the value is written from the host to the FPGA the value latches until the FPGA reads it. All of the switch behaviors are exactly the same on the FPGA, i.e. once the value is written from the host to the FPGA, the value switches until it is written from the host again.

 

This is different than LabVIEW Core because there is no notion of when pressed, when released or until released for a boolean on the FPGA front panel. Each action only has one implementation, not three.

Donovan
Message 8 of 12
(4,438 Views)

Hey Jeff,

 

According to the LabVIEW help, all of the mechanical actions do different things, depending on how long you hold down the mouse. For the above, I did the equivalent of holding down the mouse forever. For a windows VI, Latch when released would never have run. All of the signals changed at the same instance in time as well. Now that you bring it up though, I'm questioning myself... let me see if I can dig up those old tests and run this again, just to be sure I'm not spreading mis-information (I'm pretty sure I'm right, since there are only 2 implementations in the underlying VHDL).

Cheers!

TJ G
Message 9 of 12
(4,434 Views)
Solution
Accepted by WNM

Ok, looks like I have a little bit of clarifying to do.

 

First, the waveform diagrams above are correct. As soon as the Host_Write handshaking signal goes high, data is written on the next clock cycle. At this point, all "Latch" options are equivalent to eachother, and all "Switch" options are equivalent to eachother. Each takes 150ns to recieve the Host_Write signal.

 

The only thing in my above post that is misleading is when I said the transitions happen at the same time. This is not true, as the writes must happen serialy, 150ns apart.

 

In case anyone is interested, I'm attaching the test project as well as the testbench. On your host machine, just generate the files for the simulation build-spec, then replace the generated tb_NiFPGASimulationModel.vhd with the one I've attached (it's the testbench). This should be at 'C:\NIFPGA\simulation\FPGA_Boolean_Mechanical_Action\FPGA_Target\MechanicalActionTest\user'. Since the forums won't let me add .vhd files, please rename the .txt to .vhd.

Cheers!

TJ G
Message 10 of 12
(4,420 Views)