3.2 has been pulled from the website.
"This update has been removed due to unexpected issues seen by users. It will be reposted at a later time when more testing and fixing has been done."
Is there a way to use models created by LabVIEW in scan mode? I know that LabVIEW creates .lvmodel file and cRIO needs dll and .out file. The solution I was able to find is to generate c code from VI and the compile to create .out file. But this is not a good solution I think and I still couldn't manage to make it work as well.
Unfortunately there is no way to easily convert a LabVIEW VI into a model for VxWorks targets right now. This is planned for future improvement.
The best way to use custom LabVIEW code on a VxWorks target is to use a Custom Device. If your LabVIEW code needs to behave like a model, use the "Inline Model" or "Asynchronous" custom device template. You can find detailed information about custom device development here http://zone.ni.com/devzone/cda/tut/p/id/12712
Thank you for your suggestions.I also wonder if there is a way to use cRIO in Hybrid mode but I think it is also not possible for now.
I'm having some problems getting the EtherCat custom device working. I can tell that the EtherCat is working because in my Distributed System Manager the Device and it's modules are listed, and if I manually add the EtherCat master and all the modules it works, but the GUI is all messed up. Whatever website is supposed to load doesn't and the auto-detect feature isn't working.
Embedded help pages:
I have seen in some cases that Windows UAC blocks access to webpages downloaded from the internet (such as the .chm file used in the custom device). To enable viewing, right-click the downloaded file and select Properties from the shortcut menu. On the General tab of the Properties dialog box, click the Unblock button. You can find the file in the following location:
<Public Documents>\National Instruments\NI VeriStand 2011\Custom Devices\Scan Engine\data\Scan Engine.chm
I expect the problem is that you have not installed the "I/O Variable Remote Configuration Web Service" onto your real-time target from MAX. This component is required for remote communication to the target (auto-detection and EtherCAT bitfile deployment). Installation of this component is mnentioned in the "Driver Installation Instructions" section of the readme.txt included with the custom device, but it is easy to overlook this step.
We've been having an issue with the 2011 version of the custom device. Our PXI controller had been running Veristand 2010 with the custom device and everything was working fine. We upgraded our computer and controller to Veristand 2011, installed RIO 4.0, EtherCat 2.2 and I/O Variable Remote Configuration Web Service and followed the installation instructions with the latest version of the custom device. However, the Autodetect function does not work, and when we try to deploy, we get the following error message:
The VeriStand Gateway encountered an error while deploying the System Definition file.
Error 1003 occurred at Project Window.lvlib:Project Window.vi >> Project Window.lvlib:Command Loop.vi >> NI_VS Workspace ExecutionAPI.lvlib:NI VeriStand - Connect to System.vi
LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.
NI VeriStand: Open VI Reference in Custom Devices Storage.lvlib:Open Device Reference (HW Interface).vi->Custom Devices Storage.lvlib:Initialize Device (HW Interface).vi->NI VeriStand Engine.lvlib:Initialize Inline Custom Devices.vi->NI VeriStand Engine.lvlib:VeriStand Engine State Machine.vi->NI VeriStand Engine.lvlib:VeriStand Engine.vi->NI VeriStand Engine.lvlib:VeriStand Engine Wrapper (RT).vi<APPEND>
c:\ni-rt\NIVeriStand2010\Custom Devices\Scan Engine\Scan Engine RT Driver.vi
Based on the last line, we are guessing that the custom device is still trying to use the previous version, but aren't sure why it would be doing that or how to fix it.
That's a good thought about NIVS trying to use an old version of the custom device, but I don't think that's the problem. Looking at the custom device XML, I forgot to update the destination path of the custom device, so it's putting it still putting it under the 2010 directory. The location on disk shouldn't make any difference and shouldn't cause any problems.
Unfortunately I don't have an idea what might be causing your problem. It's possible that some old driver or 2010 files got left behind on the controller after the upgrade and that is causing the code to be broken. I know it's not an elegant solution, but the best course of action may be to just reformat your controller to get a "clean start" and reinstall the software and drivers. That usually solves any weird unexplainable RT issues...
Before you do that, it would be good if you could FTP into the controller and copy the following directory:
c:\ni-rt\NIVeriStand2010\Custom Devices\Scan Engine\
If you could zip that up and email me, I'll try to take a look and see if I can reproduce on my system.