NI VeriStand Add-Ons Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

VeriStand FPGA XML Builder Node Feedback

Hi Guys, If I create group "B" and nest it under "A", then I create another group "B", the node merges all the channels from the new group "B" into the nested group "B".  Basically everything in the node (inputs, groups, parameters, categories...) should have unique names to be handled correctly.  Would you please consider adjusting the tab order of the controls in the configuration dialog box to something more "top left to bottom right"-ish?  Thanks, -Steve K

0 Kudos
Message 21 of 174
(6,038 Views)

Hey Steve,

You are correct, this is a bug in my implementation of the tree control in the configuration window; Sue, a couple posts up, also noticed this. I've added this to my list of improvements to make for the node; for now, unfortunantly, the only work-around is to keep all names unique. As for tab order, that's a simple enough change to make and I hadn't noticed that the order was so random; I should be able to include that in the next release, when we fix the unique names issue. I appreciate the feedback and bug alerts, keep 'em coming!

Thanks! --Ryan_S

0 Kudos
Message 22 of 174
(6,038 Views)

Here's a strange one.  I built this interface and it failed to import into VeriStand with:

Error -2628 occurred at Invoke Node in NI_XML.lvlib:Load XML File.vi->FPGA.lvlib:Read FPGA Data Configuration.vi->FPGA.lvlib:Read FPGA Configuration File.vi->FPGA.lvlib:FPGA_Create Structure.vi->SE Actions.lvlib:Add FPGA Device.vi

When I looked at the fpgaconfig file, there were two sub-categories that I did not have listed in my XML node: one under "Motor_Drive_Group" and the other under "Timing_Group".  The names for both sub categories are blank.  When I remove the empty sub-categories, the interface imports as expected.  I'm not sure what I did to get these empty categories into the Express VI, but I can't seem to get rid of them, because they don't show up in the Express VI when I configure it.  I attached the VI and XML for your reference.  Thanks for taking a look. -Steve K

0 Kudos
Message 23 of 174
(6,038 Views)

Hi All, Please have the default scale for PWM and FXP set to 1, like the Creating a Custom FPGA Configuration File page indicates.  Currently the node defaults to scaling by 0.  Please add a Description field for categories.  From a design standpoint, what are your thoughts on uncoupling the node's configuration from the FPGA VI?  While I'm able to work-around the need to recompile when I change the XML configuration, it would be nice not to.  For example, instead of storing the XML configuration in the VI's data space, why not use the fpgaconfig file itself?  I know you you've already thought this through.  Thanks. -Steve K

0 Kudos
Message 24 of 174
(6,038 Views)

Hi Steve,

I think so.

If Default scale is 1,  We don't have to change scale of every channels 0 to 1.

And, It is  incovenient we must recompile when I change XML.

In addition to the above, I'd like the node to fit width with channel names. The node with Fixed width hide the channel name, so It is difficult to find wrong links.

0 Kudos
Message 25 of 174
(6,038 Views)

Hi all,


I don't think the XML node is inserting VOID packets where needed.  Assuming the block diagram picture generated by the node is current (please see attached), I think there should be 24 void bits between Phase_Shift_N_Samples and Fixed_AI_Sim_Voltage.  The XML does not have void bits between these two registers.

<DMA_Write>

        <Packets>4</Packets>

        <Packet>

                              <U8>

                                        <Name>Phase_Shift_N_Samples</Name>

                                        <Description>The number of samples to look-back in the 255 element RVT primary buffer to send to the RVT secondary calculation.  Each sample is 1.44 degrees, and there's a two-stage delay at N = 0.  To get a zero-degree phase shift, set N = 253.</Description>

                                        <Category>RVT_Sec_Group\LUT_Control_Group</Category>

                                        <InitialValue>0.000000</InitialValue>

                                        <Scale>1.000000</Scale>

                                        <Offset>0.000000</Offset>

                                        <Unit>N</Unit>

                                        <Symbol>AO</Symbol>

                              </U8>

                              <FXPI32>

                                        <Name>Fixed_AI_Sim_Voltage</Name>

                                        <Description>If override the analog input with a static value, use this value.</Description>

                                        <Category>RVT_Pri_Group\Pri_Sim_Group</Category>

                                        <InitialValue>0.000000</InitialValue>

                                        <Scale>1.000000</Scale>

                                        <Offset>0.000000</Offset>

                                        <Unit>Volts</Unit>

                                        <Symbol>AO</Symbol>

                                        <FXPWL>19</FXPWL>

                                        <FXPIWL>5</FXPIWL>

                              </FXPI32>

        </Packet>

The VeriStand channel is not linked correctly to these registers; the value I set from VeriStand's workspace is not the value interpreted by the FPGA.  Please let me know if I'm missing something.

I think this tool has great potential.  I also think it probably works as intended for well-aligned DMA streams and a flat channel hierarchy.  In the interest of our project's timeline we're going to revert to the manual interface.  I'll keep an eye on the thread and I look forward to an update.  Thanks for your consideration.

-Steve K

0 Kudos
Message 26 of 174
(6,037 Views)

Hey Steve, Sue,

A couple thoughts on your comments:

1. Default scale to 1 - I agree completely (and thought I had set this). This will be implemented in our next update.

2. Descriptions for Categories - I also agree that this should be implemented, but it's not clear cut with how the current tree control is managed. I'll mark this to be included in the re-architecture of the tree control that we'll be doing to eliminate the bug that doesn't allow having duplicate names throughout the tree.

3. De-coupling node configuration (XML) from the FPGA VI - We had considered this, but our primary fear was that this could lead to mismatches between the XML and the FPGA code. However, I do agree that for elements that won't cause a mismatch (changing name, scale, offset, description, etc) there should be a way to easily change the XML without then causing the VI to think it needs to be recompiled. So, I have two thoughts:

          3.1. Manipulation of the XML Outside the Node - Manually changing the XML is always an option but there's also another tool, the VeriStand Configuration Editor, that another engineer has been working on. I'm not sure on it's current state but I know its purpose is to provide easier manipulation of the XML file.

          3.2. Additional State Checks within the FPGA XML Node - It's also possible for us to implement checks within the node that wouldn't recreate the back-end code (and thus not require a recompile) unless changes that would require a recompile (change in order, change in datatype, etc) are made.

So, it really comes down to what we're trying to resolve. Is the pain point more of the need to go into the VI if you want to change the XML that doesn't really affect the compiled bitfile? Or is it that the VI thinks it needs to recompile after changing XML that shouldn't require a recompile? Thoughts?

4. Node Width Resizing - This is actually a lot harder to implement than you would initially think. We create the image for the node by programmatically drawing it. This is fairly easy when expanding vertically because we expand by a known size (one full input/output row). But expanding horizontally would mean redrawing the lengths of each row, the top of the node, etc. I agree it would be useful, and at the very least we'll look at increasing the width to a wider (but still static) size, but I'll need to think further on how we would implement dynamic horizontal resizing.

5. Void Packets - The node doesn't actually generate any void packets in the XML because I made the assumption that all void bits would be at the end of the packet when our bitpacking algorithm packs the channels. And, if all of the void bits are at the end of the packet, there's no need to actually identify them. I'm thinking this may have been a disconnect between Tim and I and we'll discuss how best to fix this bug.

6. Phantom Categories - I haven't had a chance to fully dig into the node you attached, but that's an odd behavior. I'll investigate further and let you know of any conclusions I reach.

Overall, we appreciate the feedback guys. This tool is still new, and so we expected a few bugs here and there and we're continuing development to make this tool better. Ultimately, the hope of this tool is that it will dramatically simplify and reduce the development time of your FPGA VIs for VeriStand.

Thanks!

--Ryan_S

0 Kudos
Message 27 of 174
(6,037 Views)

For 5, the bitpacking should indeed only have the void bits at the end. I am not immediately sure why there is a void inbetween but we would need to investigate.

I think we have the required information needed to reproduce.

Tim A.
0 Kudos
Message 28 of 174
(6,037 Views)

Hi Ryan,

Ryan_S wrote:

So, it really comes down to what we're trying to resolve. Is the pain point more of the need to go into the VI if you want to change the XML that doesn't really affect the compiled bitfile? Or is it that the VI thinks it needs to recompile after changing XML that shouldn't require a recompile? Thoughts?

IMO, the pain point is recompiling the FPGA VI.  It's no biggie to perform the edits from the VI.

Ryan_S wrote:

          3.1. Manipulation of the XML Outside the Node - Manually changing the XML is always an option but there's also another tool, the VeriStand Configuration Editor, that another engineer has been working on. I'm not sure on it's current state but I know its purpose is to provide easier manipulation of the XML file.

I wish we had time to give it a try, but we can't risk any more time.  Thanks for the link and maybe we'll try it on the next project.

Best, -Steve K

0 Kudos
Message 29 of 174
(6,037 Views)

Hey Steve

Ryan_S wrote:

So, it really comes down to what we're trying to resolve. Is the pain point more of the need to go into the VI if you want to change the XML that doesn't really affect the compiled bitfile? Or is it that the VI thinks it needs to recompile after changing XML that shouldn't require a recompile? Thoughts?

IMO, the pain point is recompiling the FPGA VI.  It's no biggie to perform the edits from the VI.

That's good to know. I've added that to our task list, and we should be able to avoid a recompile when XML values that don't affect the back-end code are changed. We'll keep you posted as to when these are incorporated in new releases.

--Ryan_S

0 Kudos
Message 30 of 174
(6,037 Views)