XNET Convert Data Types

[Hardman125]

We are trying to convert J1939 CAN frames to their respective signals.

Attached is a simplified version with one ECU address. We have the filter working fine, but the conversion vi wants a "frame data" were as we can only give "data".

We are able to view info in the frames and can do a conversion through brute strength, but it seems like the XNET Convert should already handle this.

The point of this program is to view signal values from several recorders separably and later save for reports.

[Trevor.H]

Hi Hardman125,

You may want to give the "CAN Signal Input Single Point.vi" example a look.  You can find it in LabVIEW under Help>FInd Examples....  If you read the signal data directly using one of the options under "Signal" in the drop down, you won't have to use the convert function at all.

[Hardman125]

We tried that last week. The issue is that we have multiple 3 frames and 11 ECUs and have not found a way to sort which signal is coming from where with that method.

The vi we are working on is able to sort by the ECU identifier, but without the conversion vi, we basically have to recreate the database in LV and make the conversions by brute force. And by brute force I mean, convert the correct bytes into hex, combine hex characters, convert back into decimal, then add our scale/offset to get engineering units. It works, but that's a lot of editing when the database changes. (Another department controls the database, we're just responsible for testing the end system)

Do you know a way we're missing that we can still use to identify the ECUs?

[Trevor.H]

Our go to method for developing such systems is to define everything from within the NI-XNET Database Editor.  Since you don't control the database, that does complicate things.  Is this the same database being called at the XNET Create session frame list?

[Hardman125]

I'm assuming it is the same since it is pulled into the session and the session is passed through to the conversion vi (shown in conversion1.png)

The input in the pic only shows the two frames being pulled in, but that input first asked for a database before presenting a list of frames to choose from.

When we try to simplify the vi to just session create/read/convert for troubleshooting, we still have the same error. So that rules out anything with the loops or case structure too.

Error - 1074384753 occurred at XNET Convert (Frame CAN to Signale).vi:4090001

Possible reason(s):

NI-XNET: (Hex 0xBFF6308F) The function you called is not defined for the session mode (e.g. you called a frame I/O function on a signal I/O session).

[Trevor.H]

The XNET Convert.vi expects a session in Conversion Mode.  XNET Write and Read are not compatible with Conversion mode.  Since the error is being thrown at the XNET Convert, not the Read, we can assume your session is not in Conversion Mode.  

To fix this, try creating separate session to wire into the into the XNET Convert.vi

[Hardman125]

Was hopeful on this one since we haven't tried multiple sessions. But attached is a simple VI with the same error. 

For now we had to replicate the database in our VI so we can proceed with testing. This works but, becomes a pain if the database needs to change and cannot simply copy/paste for the next test.

[Trevor.H]

I'm glad we were able to resolve that first error.  Now to tackle the new one.

It seems the XNET Database for the Conversion session is not formatted for this  kind of session.  I tried running a convert session with dummy data, and found it was able to run with the NI-XNET example database for CAN.  Getting more detail on your database leading into the Conversion session could be useful in troubleshooting this error.

[Hardman125]

Sorry, I didn't see your response until today.

What information would you need from our database? We're getting into some proprietary stuff here, so I may not be able to share it on the forum.

After writing down the general layout of our DB below, I remembered running the conversion examples. I don't remember seeing anything with a muxed signal.

The main rundown of our DB:

1. Main Cluster - J1939
   1. Frames
      1. Frame A
         1. Signal A1 - muxer
         2. Signal A2 - muxed on x10
         3. Signal A3 - muxed on x10
         4. Signal A4 - muxed on x11
         5. Signal A5 - muxed on x11
      2. Frame B
         1. Signal B (no mux)
   2. ECUs
      1. ECU A (ECU A is a separate PLC that runs the system, but for the signals that we are interested in, this ECU only receives. We have it in there because later we want to record when certain commands are given)
         1. Recieve Frame A
         2. Recieve Frame B
      2. ECU B
         1. Transmit Frame A
      3. ECU C
         1. Transmit Frame A
      4. ECU D
         1. Transmit Frame B
      5. ECU E
         1. Transmit Frame B
      6. ECU F
         1. Transmit Frame B

[Trevor.H]

Thanks for looking that over.  I'm going to take a dive into the XNET user manual and see if I can get some more clues on this.