06-02-2014 08:54 AM
That's certainly interesting, and I'll see if I can reproduce that behavior here. The .NET control that I use for the preview tree receives the same information that is sent to the XML generation functions. So, since the VeriStand Preview tree is showing up properly, then the generated XML should also be correct.
06-02-2014 09:24 AM
After looking at the code for how we parse the LabVIEW tree, it looks like we have a bug in how we handle glyphs when a channel and category are the same name. So, that explains the glyph behavior of the RVT_Primary channel and category. I assume with the RVT_Secondary category that there's also an RVT_Secondary channel. I'm unsure what's affecting the AI0_Code and AI0_Voltage channels, but it may be a carry over from the other affected channels. This behavior shouldn't be linked to when the inputs/outputs are created (before or after first XML generation) and also should not affect the validity of the XML that is generated.
Overall, it appears that this is a cosmetic bug but I'd like to investigate further to be absolutely sure. Would you be able to attach your VI?
06-02-2014 11:44 AM
Hi Ryan, Thanks for offering to take a look. I can't send my VI but I've attached the interface in case it facilitates troubleshooting. I don't notice the display glitch until I exit the node, so I assumed it was after XML was generated. Thanks, -Steve
06-02-2014 02:26 PM
I appreciate the VI, all I need is the instance of the node so that I can extract its state information and debug further on my system. I'll let you know more after I've had a chance to look at it further but it appears to be the cosmetic bug I thought it was and is caused by channels with identical names. However, these channels don't technically have identical names because they're in different categories so I'll have to investigate where the name collision is occurring. If you change the names of the four channels experiencing the bug (double click on their names in the LV tree to edit) to something slightly different (add a 1 or some differentiation, it looks like you may want your first two inputs (index 0 and 1) as AI1 instead of AI0 anyway), then the save changes & close, then re-open the config window you'll see the behavior goes away. Good news is the XML and backend code generated shouldn't be affected but I'll confirm this as I test further.
EDIT: After testing, I've concluded that this bug is caused by how I'm creating and storing the tag names for the items in the LabVIEW tree. Luckily, this bug is completely cosmetic; the proper tree layout is still shown in the VeriStand Preview Tree and this bug does not appear to affect the XML or underlying code that is scripted. However, one additional behavior to be aware of, if you have multiple channels/categories with the same name and you use the subpanel to change the name of the channel/category without a glyph, it will actually rename the channel that does have a glyph. This still has to do with the tag names but is a separate routine I'm running and none of the other information in the subpanel is affected. If you rename either channel by double-clicking in the LabVIEW tree, that still works properly.
Overall, changing these channels/categories with duplicate names to have unique names resolves this bug. I've updated the known issues list on this Add-Ons homepage to include this bug.
06-13-2014 08:35 AM
I created FPGA program by using usual blocks.
but XML config file is difficult to edit, so I am trying to replace the blocks with this node.
This node looks very useful.
My program has about 150 channels, but the maximum number of channels which this node can be connected is limitted to 100.
Can I increase or remove the limit?
06-13-2014 09:07 AM
We set the limit at 100 arbitrarily as we werent sure what the upper bounds might be. We should be able to increase it for you without too much concern. One clarifying question though. What do you think is the MAX that you would ever need to use? I don't want to set it at 200 and have you stuck if you want to add one more hehe
06-13-2014 05:51 PM
As Tim mentioned, the initial limit of 100 that we set was arbitrary and didn't take into account the maximum number of I/O that could be transferred for some FPGA targets and/or additional channel values that a user may wish to send or receive from NI VeriStand. So, we've increased the limit to 500 and I've uploaded the new version (1.0.1) to the Add-On's page. So, you'll want to download the new VI Package and run it to upgrade the files on your system. Then you'll be able to drag the node down past 100 inputs/outputs.
06-14-2014 09:17 AM
Hi Timothy, Ryan,
Thanks for Improving the node.The number of Channels never exceed 500 in my VI.
It works almost well, but there are some issues.
1. Same category name.
I want to create categories as below.
but If there are already exist category which have same name, I can't save new categories properly.
2. Character code
On my environment, After Loading generated XML in Veristand, it shows me error.
So I opened XML with Notepad and convert character code from "ANSI" to "UTF-8".
Then, It works well.
I think the issue caused by my japanese environment.
3. Import existing XML (request for improvement)
When updated and replace this node in future, we may have to reconfigure setting.
It would be nice to have the"import XML" button.
06-16-2014 08:47 AM
I think Ryan might have some more insight for us on your first question.
A non-English OS can cause issues like this. In the future, it would be interesting to look at which specific character the XML load is calling out as a problem. We could try to track it down in XML and figure out what might have created it initially.
That's a great idea! Thank you for that feedback . It likely wouldn't be too complicated to create that either. I will add it to our list of backlog tasks and try to start working on it soon.
06-16-2014 01:33 PM
For #1, that's an interesting bug and its root cause appears to be what also causes another cosmetic bug that I've documented as Known Issue #2 on the product page. Basically, I'm not properly handling the underlying tag names that are used for the LabVIEW tree I've implemented. I'm going to investigate this further and, after I confirm the root cause, I'll add it to the known issues list as well. The reason this didn't come up during testing is I usually implemented a structure similar to:
The workaround, for now, is going to be to use unique category names such as the example above. I also agree with Tim that #3 is a great idea and we'll look at how this can be implemented into future versions of the function.