VeriStand does not output PWMs

[joedowdle]

So I followed the FPGA Personality Example for varying frequency and duty cycle (https://decibel.ni.com/content/docs/DOC-16699) to do the same thing in my program.  I need all my channels to vary and I have 56 channels so I basically took the idea behind the original PWM out and stuck four of them into one subVI.  I also grouped my packets as one U32 for frequency and one U32 for duty cycle in the same U64 packet rather than having just frequency's in a packet and just duty cycle's in a packet.  I didn't put the time loops inside the main while loop either.  I kept them on the outside of the frame like the VeriStand FPGA Wizard sets it up.

I had it working before with VeriStand FPGA based I/O tools but needed to be able to adjust frequency and not just duty cycle so I turned to this.  I cannot get it working and cannot figure out why it doesn't work.  I have included a copy of my subVI and a screen of one of the packets in the XML file.  Any input would be appreciated, thank you.

[StephenB]

Can you post the top level VI? the subVI looks fine. Also, what hardware are you using?

[joedowdle]

Here is a screenshot of a portion of the top level VI (you can't see all the channel loops but it's just a copy/paste type thing).  The first 11 packets are for a quadrature output so that can be ignored for this.  The packets for the PWM are the last for loop of packets (56 total).  The subVI with the blue top and "4 CH. PWM GEN" is what I posted earlier.  I am using a PXI-7813R FPGA for this and it is connected to a C-series chassis with 9474 modules in it. Thanks for the help.

[StephenB]

I dont see anything obviously wrong. Couple of things you can check:

• Do you mean to be reading 8 DMA packets in the second for loop and then only using 4 of those 8 packets? Seems strange.
• Does your .fpgaconfig have 1 DMA packet for read and 68 for write? That is what I see in your code, just make sure it matches the .fpgaconfig
• The default DMA size on the project is 15 elements, you need to make sure the DMA_WRITE size is increased to at least 68 elements

[joedowdle]

I appreciate the help.

The only reason there is 8 in the second for loop is because of the way the .fpgaconfig file is right now.  It will not be there when I am finished; it is temporary. I didn't want to delete a portion of my .fpgaconfig file if I will still need it.

My .fpgaconfig file does much the 1 packet for read and 68 for write.

I was hoping when you mentioned the last one that, that would be it but I had changed it before to 1023 just to make sure I wouldn't have any problems with that.

I'm not sure why it's not working. Would it make a difference it it's not in a timed loop?

[StephenB]

Rats...

Yes you need the timed loop because of the way the PWM generation express VI works. It does a point by point generation which is best suited for your hardware since it has fast digital lines.

What symptoms do you see? Do you see nothing output on the digital lines at all?

One thing you can do to debug is connect to the FPGA VI remotely while it is running, so you can see its front panel.

1. Run the NIVS project as is
2. Open up your source LabVIEW project (the one that you made the FPGA bitfile with)
3. Verify the RIO Resource name is filled in on the FPGA device (should be RIO0 or RIO1... etc... on the properties of this item) and the device is under my computer if you're hardware is local or an RT target if the device is remote (and the ip is correct)
4. Then just open up your FPGA VI and click run. It will connect to the running FPGA and allow you to see its front panel.

[joedowdle]

Wow... all this trouble and I feel a little dumb for a lack of better words.  Turns out I had the 32-bit part of my packets mixed up in my config file - frequency was duty cycle and duty cycle was frequency.  It seems to be working now testing it by viewing the front panel.  I will check it with a scope later this afternoon.

Thanks for the help with this.

[StephenB]

Woohoo. Glad you figured it out 🙂

[joedowdle]

So, a question about your method of debugging using the front panel.

 I am trying to view the front panel of my FPGA while running my VeriStand project to verify that some of the quadrature components I'm implementing are working before doing a hardware test and I keep getting an error.  I had it working just fine earlier, but realized that I had something wired wrong so I changed it, recompiled, and now I get an error that reads:

"The operation could not be performed because the FPGA is busy operating in FPGA Interface C API mode.  Stop all activities on the FPGA before requesting this operation."

This error comes up after I deply my VS project and hit the run button on the front panel.  If I undeploy my VS project and try to run the front panel the error disappears.  Any idea why this error would suddently start appearing after recompiling?

[StephenB]

The NIVS engine does access the FPGA via the C interface... but I've never had this problem before. You should be able to simultanously access it remotely from LV on your host computer and while the NIVS engine accesses it on an RT machine.

That brings up a good point - ive never tried this trick when the NIVS engine was running on windows. Is that what you're doing? Perhaps that is not supported...