02-23-2012 03:00 PM
Devin,
I reformatted the controller and reinstalled everything and we are still getting the error. I'll get the files zipped up and email them to you.
Thanks,
Dustin
02-24-2012 01:58 AM
I had the same problem with the AIT 429 Custom Device.
In fact the directory specified in the Custom Device is NIVeriStand2010. It seems that with VeriStand 2011 the custom device is loaded in the new directory NIVeriStand, even if the directory in the XML file was NIVeriStand2010, but the VeriStand Engine try to execute the custom device from the specified directory NIVeriStand2010.
The workaround is to update the custome device XML to replace NIVeriStand2010 to NIVeriStand (and eventually to suppress the NIVeriStand2010 directory on the target).
I don't understand why the loading iis not in the specified directory with these custom device, because with our own custom device, we specify a different directory and it works fine.
Hubert
02-24-2012 09:22 AM
Hubert,
Are you saying that when you had the AIT 429 custom device in the NIVeriStand2010 directory you were getting the same "Error 1003: VI not executable" error that Dustin is now seeing with the Scan/ECat CD? That is definitely very strange, and not something I have seen before
02-24-2012 11:31 AM
Yes, I confirm.
Hubert
02-24-2012 04:51 PM
Agreed, this is something I have not seen.
The directory on the RT target shouldn't matter, so the fact that it is in an old directory hasn't really concerned me in the past. It is something that should get fixed, but not something we prioritized because I've never seen it cause an issue. Obviously, we have tested these add-ons before posting them... and they worked fine.
However, I want to get to the bottom of this, so I will set up a system next week with an AIT 429 card, format it, and install NIVS 2011 and the custom device. If that works, I'm going to try formatting it, installing NIVS 2010 + custom device, and then upgrade to 2011.
I'll also take a look at the EtherCAT situation.
02-26-2012 12:09 PM
Stephen,
As I needed to configure a new system with AIT 429 card, I have done the install step by step to confirm.
At the beginning, only VeriStand 2011 and the NI drivers (version August 2011) were installed on the PC host (Windows 7 64bit french).
On the PXI target, we had installed the software from scratch with MAX.
Following are my steps for the AIT 429 installation :
I hope this could help you.
Regards,
Hubert
02-27-2012 02:21 PM
That certainly should not be happening. You shouldn't need to install the AIT 3.5 driver, install LabVIEW, or modify the custom device XML to point to a different directory. I apologize for all the trouble.
Since the readme for the AIT 429 Custom Device includes instructions to FTP the DLLs to the target, you don't need to use the LabVIEW utility to "install dependencies to RT target".
To better diagnose the issue, I reformatted a PXIe-8108 controller and set up a brand new clean Windows 7 64-bit virtual machine. I then installed NI VeriStand, DAQmx, and followed the install procedures described in the AIT ARINC 429 custom device.
After following the steps, I too saw the broken main page as you did in "ARINC CD Page Error.PNG". I found that the "DLLs" folder was missing four files from the driver that should have been included and NI-VISA Run Time Engine needs to be installed. After fixing this problem I was able to use the custom device in the system explorer.
When I deployed the custom device, it threw error 1003 claiming it was broken. I determined this is because when upgrading this device to NIVS 2011, I changed some code to place dependencies inside c:\ni-rt\NIVeriStand\Custom Devices\AIT 429 however, I never updated the XML to place the driver VI inside that directory.... so the dependencies were in two different locations.
I will update the ZIP file for the AIT ARINC 429 Custom Device to include the extra 4 DLL files, updated readme listing NI-VISA run time engine as a required install, and fix the XML to place the driver VI into c:\ni-rt\NIVeriStand\Custom Devices\AIT 429
02-27-2012 03:13 PM
Updated it: NI VeriStand Add-on: AIT ARINC 429
02-29-2012 03:40 PM
We got our system up and running again, but we seem to have encountered a weird bug in the process. We tried testing the custom device with the included XML file (which puts the files in the Veristand 2010 directory on the controller) and an updated one that Devin sent us that uses a different directory. Both work, but the first time we deploy either one to a "clean" system, the deployment will fail with the "The VI is not executable" error message. If we reboot the controller, it will load the Veristand setup automatically and every thing works fine. Also, any subsequent deployments seem to be working. But the initial one will fail repeatedly until you reboot the controller. Our process was: undeploy setup, close Veristand, delete custom device files on the controller, swap out the XML file on the lab computer, reopen Veristand, delete existing EtherCAT custom device from system definition, recreate custom device, attempt to deploy to controller.
Has anyone else seen this issue? We had a lot of problems similar to this with the initial Veristand 2010 release, but they appeared to have been resolved in one of the Veristand or Labview RT service packs. We're hoping this issue hasn't come back in 2011.
Thanks
03-01-2012 03:59 PM
Hi Dustin,
I can reproduce the behavior you're seeing with the Scan Engine custom device, but not in the general case with another simple custom device. I don't know exactly what is happening, but I expect certain files (likely all the classes in the packed library) are staying in memory which causes problems when the custom device is re-run at a different location on disk. Rebooting the controller fixes the problem since everything gets cleared out of memory.
I'd like to find out exactly what's going on, but I don't think it should cause you too many problems, since this should only occur if you're changing locations or possibily upgrading the custom device without rebooting the controller. I don't think you should see this problem in regular day-to-day operations, like you may have expereienced in 2010.