06-30-2011 09:19 AM
I posted something similar to this earlier and thought I had it all figured it out. Turns out I'm only part way there and it's getting more in depth so I reposted. What I want to do is have the user choose a CAN database (.dbc) file and pass the file path of the database to the sub VI. That part works great.
The user then needs to be able to choose the frame needed for their test and therefore I need to open the database to get at the frames. I found a String to I/O converter in the advanced tab of XNET. This made it possible to get at the database. Then I used property nodes to get at the cluster and then from the cluster get at the frames. (I've included a screenshot of this portion of my code so it's easier to follow.)
The problem I'm having is that this process creates an array of I/O frames and each element of that array is one of the frames. Rather if you were to "Browse for XNET Database..." they all show up under one I/O drop down menu rather than an array of these menus. (Refer to the second screen shot to get a better idea what I'm talking about.)
What I've Tried:
I tried to work around this by populating a ring with the String[] property node and then just pulling out the frame using an index array function. This does what I want I to do, but then I have to create an array of the same frame in order for the XNET Create Session block to accept the value. This makes it so I get an XNET Session Error about having multiple frames that are the of the same name/same signals.
This may or may not be relevant, but I also have been getting some baud rate setting errors. I have that set to 500k which is the proper rate for our HS CAN. Not sure why that has been popping up, but I figured I'd mention it.
I really hope someone can help me out with this; I've done many searches and have come up with nothing and this is a very important aspect I'd like to implement into my program.
06-30-2011 09:45 AM
07-01-2011 07:00 AM
I am using the Ouput Frame, but I did manage to figure out that part and now ran into another problem.
It turns out that the problem I was having was a lot more simple than I was approaching it as. Even though it wasn't listing all of the frames in one drop down, I could just make a single element array with the one I wanted. I used a ring property node to populate the ring and then choose from the ring which one I wanted to use. Then I used that combined and in indexed array block to get the element I needed. Then just converted it to the array. The baud rate issues were exactly as you suspected and were resolved by defining that in the cluster property node.
THE NEW PROBLEM
Now the problem comes in to play when I create an application of this whole project. At first, I had some issues getting the correct file path pase from one program to another, but now I have verifired that the correct path is going into this application. Somehow it just disappears though at the cluster property node. If I stick an indicator on it I get an empty array... and the on the otherside of it I have the database file. Any thoughts on what might be causing this?
Thanks and I appreciate all the help.
07-01-2011 07:21 AM
Can you post the part of your vi where the path disappears?
I suspect there may be something in the Project settings which interferes with dynamically loading databases.
From the XNET-Help:
The NI-XNET session in a LabVIEW project assumes that you have a database file. The configuration dialog includes controls to browse to your database file, select a cluster to use, and select a list of frames or signals. For example, if you create a Signal Input Single-Point session, you enter the database and cluster to use, then select one or more signals to read.
It's a complete guess on my part but I'm wondering if XNET is locking onto a particular database associated with the project.
07-01-2011 08:43 AM
Thanks I appreciate the help. When I run the application it takes the path and every time there is a space it just to another element in an array. So I just wrote a little code that concatenated each element and put the spaces back in so that the path is now correct. It turns out that after doing that there was a space left over at the end of my path... and LabVIEW didn't like that.