Can't use CAN2 on PXI-8513/2

[NathanJD]

I am using NI-XNET CAN in a VeriStand model running on "NI Real-Time Phar Lap ETS 13.1" (inherited project).  It is currently working using CAN1 configured as 'Frame Out Stream' but fails when I try to use CAN2 instead.  The error code (as far as I can tell) is zero.

One thing that I noticed is that there are no ports configured in the VeriStand System Definition file (but both ports are defined as shown in MAX though).  I thought that maybe this was the cause and was planning on this being my first troubleshooting step.  However, when I tried to add the port(s) to my System Definition file, it wouldn't let me not have a database (because I don't have a database for my purposes).

So, any ideas as to why I wouldn't be able to use CAN2?  If adding it to the VeriStand definition is a requirement, how do I add the port without a database?

[Shane-C]

Hello,

Can you upload screenshots, or the actual system defenition file that show how you have the first port configured in NI VeriStand that is currently working?

[NathanJD]

That's the thing, none of the CAN ports are configured in the VeriStand System Definition file.  When I mentioned CAN1 being configured as "Frame Out Stream", I meant that it was initialized in the model using "XNET Create Session (Frame Output Stream).vi" with CAN1 chosen as the 'interface'.

Both CAN 1 and 2 show up in MAX e.g.  Remote Systems > Real-time Controller > Devices and Interfaces > NI PXIe-1071 "Chassis 1" > 2: NI PXI-8513 "CAN1,CAN2" > CAN1.  The LEDs for each of the ports on the PXI card blink appropriately when I select either port in MAX.  (Slot 1 is the NI PXIe-8360 "Remote Controller").

[Shane-C]

That is what I wanted to verify.  I was wondering how you were able to get one of the ports to show up in NI VeriStand without a database file.  I do not believe that there is a way to do this, none that I can find anyway.

[NathanJD]

So, without it being defined in the system definition file, I can use CAN 1 but I can't use CAN2.  It's strange that I can use one but not the other.  If you don't have any ideas why this might be, I'll have to do better debugging with a fresh application to get more information.

[Shane-C]

Well, my point was that I'm not even sure how you got one port to work.  The expectation when using NI VeriStand to interface with a CAN bus, is that you'll use a database as well.

[NathanJD]

I am very 'green' when it comes to CAN communication so please forgive me if this question seems bizarre.  Can I give it an empty database (or fake database) and then still use it for "Frame Out Stream"?  We are simply providing the Identifier and the data payload to be output on the CAN bus and don't want to have to populate a database with all of the possible CAN messages that may or may not get used.

[Shane-C]

I've not tried to do exactly that before, but I do believe you could do something like that yes.  Simply connect a "fake" database, or the default example one, and then use the raw frame input mode.  I think that should get you roughly where you want to be.  

[NathanJD]

I tried to add a CAN port with the example database to my system definition and it failed to load to to the RT Controller (that was the only thing that I changed).  So, I decided to go back to basics and perform a loopback test as shown here but I get the same error.  Prior to the error, it spends several minutes on "Processing Action on Deploy VIs..." and then finally continues and fails.  Error 1 is the seems like the worst error because it seems to be the "catch all" error.

• Start Date: 3/18/2015 11:06 AM
• Loading System Definition file: C:\Users\Public\Documents\National Instruments\NI VeriStand 2013\Projects\CAN Loopback Test\CAN Loopback Test.nivssdf
• Initializing TCP subsystem...
• Starting TCP Loops...
• Connection established with target CAN Loopback Controller.
• Preparing to synchronize with targets...
• Querying the active System Definition file from the targets...
• Stopping TCP loops.
Waiting for TCP loops to shut down...
• TCP loops shut down successfully.
• Unloading System Definition file...
• Connection with target CAN Loopback Controller has been lost.
• Start Date: 3/18/2015 11:06 AM
• Loading System Definition file: C:\Users\Public\Documents\National Instruments\NI VeriStand 2013\Projects\CAN Loopback Test\CAN Loopback Test.nivssdf
• Preparing to deploy the System Definition to the targets...
• Compiling the System Definition file...
• Initializing TCP subsystem...
• Starting TCP Loops...
• Connection established with target CAN Loopback Controller.
• Sending reset command to all targets...
• Preparing to deploy files to the targets...
• Starting download for target CAN Loopback Controller...
• Opening FTP session to IP 192.168.0.15...
• Processing Action on Deploy VIs...
• Deploying XNET database: NIXNET_example
• Gathering target dependency files...
• Downloading CAN Loopback Test.nivssdf [50 kB] (file 1 of 4)
• Closing FTP session...
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
The VeriStand Gateway encountered an error while deploying the System Definition file.

Details:
Error 1 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

Possible reason(s):

LabVIEW:  An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488:  Command requires GPIB Controller to be Controller-In-Charge.
=========================
NI VeriStand:  TCP Write in NI_FTP.lvlib:FTP Command.vi:5860050->NI_FTP.lvlib:FTP [MKD].vi:3150001->FTP.lvlib:FTP MKD Recursively.vi->System Definition Deployment.lvlib:FTP Target Files.vi->System Definition Deployment.lvlib:Check and Deploy Files.vi->System Definition Deployment.lvlib:Deploy Target Files.vi->System Definition Deployment.lvlib:Deployment Dialog.vi->NI VeriStand Server.lvlib:NI VeriStand Server.vi->NI VeriStand Gateway.lvlib:VeriStand Server Wrapper.vi

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
• Sending reset command to all targets...
• Stopping TCP loops.
Waiting for TCP loops to shut down...
• TCP loops shut down successfully.
• Unloading System Definition file...
• Connection with target CAN Loopback Controller has been lost.

[ErinDavey]

Hello NathanJD,

Have we double checked that your CAN channels are named the exact same way as they appear in MAX? The name is case sensitive and needs to have the exact same name for it to be able to recognize it.