NI VeriStand Add-Ons Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Scan Engine & EtherCAT Custom Device Feedback

The problem is...If any VI in your project is referencing the library, LabView makes you resolve the conflicts every time you open the project simply because the library is loaded and has a conflicting VI.  If you have two of the same VIs loaded in memory it is a problem.  The "Scan Engine - Configuration.llb" should have referenced the vi.lib\Utility\error.llb.  I have found other similar conflicts that I am uunable to fix. 

0 Kudos
Message 251 of 676
(1,559 Views)

Download the source code of the scan engine custom device, delete the LLB's from your computer, and relink your code to the source instead of the LLBs

Stephen B
0 Kudos
Message 252 of 676
(1,558 Views)

I have a 9082 that is not reading a 9213 T/C card correctly.  I am always seeing ~4200 F in Channel one and zero on the rest of the channels.  When I input a signal on ch1, the 4200F moves to ch2 and ch1 reads correctly, but if I input a signal on any other channel nothing shows up.  My setup is as follows

Slot 1 = 9205

Slot 2 = 9264

Slot 3 =9213

Slot 4 =9213

Slot 5 =9265

Slot 6 =9411

Slot 7 =9425

Slot 8 =9476

The 9213 is configured for deg F, High Speed, type K T/C

I have doubled checked the wiring.  I have uninstalled all the modules except a 9213, and swapped slots with no difference seen.  I am running VeriStand 2013 SP1, NI RIO 13.0 (I have 13.0.1 installed on the host, but I can't get it to load to the 9082 crio which shows 13.0).  I am using 4.1.3 of the AddOn. Scan engine 4.2, RIO IO Scan 13.0, Industrial Comm for EtherCAT 2.6

Please help me figure out what is going on.

Thanks!

0 Kudos
Message 253 of 676
(1,558 Views)

The 9213 module has the ability to detect and report open-thermocouple channels.  In the past this was possible from the FPGA, but was not in the scanned API.  In NI-RIO 13.0, behavior was changed so that errors would be reported by the scan API if an open thermocouple channel was detected.  Unfortunately once an error is detected, the rest of the channels in the module are not updated.

We were able to modify the custom device to avoid having this error shut down the custom device, but unfortunately the behavior still persists where all channels are not updated.  There are open CARs with the RIO team about the issue, but I do not know if and when these will be addressed (there are some implementation details which make this non-trivial).

Until then, the only workaround is what you found out yourself: you need to wire up your thermocouples starting from channel 0, and not skip any open channels. (ex. wire up chanels 0, 1, 2, 3, 4 and have channels 5-15 empty).

Regards,

Devin

0 Kudos
Message 254 of 676
(1,558 Views)

BUMMER .  Thanks for getting back to me on this.  I originally prototyped this system in VS2011 without any issues, but VS2013 has been a fight.

0 Kudos
Message 255 of 676
(1,558 Views)

Sorry Joshe! The 9214 does not have this issue (because you can disable open TC detection) if you are willing to change modules.

Until then we have to wait for a fix from our driver team

Stephen B
Message 256 of 676
(1,558 Views)

Stephen,

I have an issue I've seen several times in the last couple of days.  I'm aware that using User Defined Variables on a Local Chassis is a relatively new feature.  I've discovered a scenario in which the sysdef and the target get out of sync. 

I added a bitfile, deployed it, and it ran well.  I then had a new verison with most of the channels in common (I added a couple of new UDVs).  I used the "Select/Change FPGA Bitfile" button on the User Variables section in the system explorer to move it to the new version.  It appeared to work just fine.

When it deployed, it caused an error 537705, "A User-Defined Variable (UDV) configured in the system definition was not found on the target."  Various combinations of either restarting the target or deleting and re-adding the custom device worked to fix it on different occasions.

Could there be code in the "Change bitfile" portion that misses some detail that could leave it out of sync?  One special case to keep in mind (which was one of the things I did, thought it definitely errored in more general cases) is that one change I did was to only change the fixed point data type of a UDV. 

If you need help reproducing it, let me know and I can provide some files - I suspect it won't be very difficult.

Thanks,

Andrew

0 Kudos
Message 257 of 676
(1,558 Views)

Hello Stephen,

I am trying to compile EtherCAT Custom Device for VeriStand 2014 and its asking for Modules.lvlibp (Packed Library) where do I get that from? Would I have everything I need to re-compile EtherCAT for 2014?

Regards,

Usman Khan

0 Kudos
Message 258 of 676
(1,558 Views)

Hey Usman,

Building this custom device is unfortunately quite complicated. We actually have an automated system for it (and all our custom device builds). I hope to have this done soon for 2014 so you dont have to build it yourself.

If you dont want to wait for that, this is what you need to do for pharlap (PXI) and windows (I omitted Vxworks):

  1. Run "\Scan Engine and EtherCAT\FXP LLB Scripting Source\Script FXP Read.vi"
  2. Run "\Scan Engine and EtherCAT\FXP LLB Scripting Source\Script FXP Write.vi"
  3. Open "\Scan Engine and EtherCAT\FXP LLB Scripting Source\FXP LLB.lvproj" and build the build spec "FXP LLB" under my computer
  4. Open "\Scan Engine and EtherCAT\Classes Source\Modules.lvproj" and build the build spec "PharLap" under the RT PXI target
  5. Open "\Scan Engine and EtherCAT\Custom Device Source\Scan Engine.lvproj" and build the build spec "Configuration - Release" under My computer
  6. Open "\Scan Engine and EtherCAT\Custom Device Source\Scan Engine.lvproj" and build the build spec "PharLap - Release" under My computer

I think that should do it.

Stephen B
Message 259 of 676
(1,558 Views)

Hello,

I'm using a cRIO 9082, NI 9205 (AI) and NI9862 (XNET - CAN). I have created a custom FPGA file with the NI VeriStand PFGA-Based I/O Interface Tool (Scan Mode is not desired). I have tested it for the NI9205 and it works fine. The next step was testing the NI9862 and it also works (I followed the instructions on http://www.ni.com/tutorial/14706/en). Using both cards (adding a CAN Port) I get Error 66 durring deployment procedure. For the 986x Support I use the same bitfile as for the FPGA target. This bitfile already contains the NI9862 Card.

Is it possible to use an FPGA target with a CAN Port in VeriStand? (two bitfiles for one FPGA RIO device adress- one for the FPGA target and one for the 986x Support in the CAN Port Settings or maybe the limitation of DMA Channels)?

Is it necessary to use the 986x Sopport in the CAN Port Settings when the card is already added in the compiled FPGA file? Which files should be used?

Thanks,

Arnold

0 Kudos
Message 260 of 676
(1,558 Views)