Loop rate is slow

[Craig Cloud]

Just received my Chipkit WF32.  Been playing with it using LabVIEW and I find that the loop speed is only 63 Hz when scanning a digital input (one of the push buttons).  The PIC32 chip runs at 80 MHz so this is way out of line.  What an I missing here?  I don't think  using LabVIEW would slow it down that much.

[D@n]

@Craig Cloud,

Testing whether or not labview is the problem shouldn't be too hard ... disconnect from it, and toggle an LED every 2^k times through the loop.  (Adjust k 'til you can see it toggle.)  Time 20 blinks, divide by 40*2^k, and ... see if it runs any faster.

Dan

[Craig Cloud]

D@n

From what I see, it is possible to deploy a VI to a BeagleBone or Raspberry Pi but not on Chipkit or Arduino. 

[D@n]

@Craig Cloud,

Yes, I've used VI (or more accurately vim) on both a BBB and an RPi2B.  Why would you need VI on a chipkit though?  It hosts a bare basic board with no filesystem.

Dan

[Craig Cloud]

@D@n

I think you are confused.  a VI is a "Virtual Instrument" which is the name for a LabVIEW program.  I wrote a program in LAbVIEW and then ran it on the Chipkit WF32.  My problem is that the program is only running at a speed of 63 Hz.  

[D@n]

@Craig Cloud,

Yeah, I must be.

Do you need to run your program with labview?  Is that an integrated part of your program, or a debugging feature that can be removed?

Dan

[Craig Cloud]

@D@n

 

Yea, I need to use LabVIEW.  It's the programming language I know...

[D@n]

@Craig Cloud,

Sigh.  It's the one language I don't know.    Let's see if one of the other moderators with more experience with the ChipKits might know what's going on.  @JColvin perhaps?

Dan

[jpeyron]

Hi @Craig Cloud,

I did find a few threads on Labview MakerHub's forum that talk about slow speed in the loop here and here. Our LabVIEW person has not yet come in today so you might not get a more experienced response on this forum until earlier next week. I would also suggest to reach out to the Labview Makerhub forum as well here. Also have you looked at this tutorial? Here is a getting started with the chipkit WF32 and Labview tutorial as well.

cheers,

Jon

[jpeyron]

Hi @Craig Cloud,

I talked to @JColvin and it turns out that Labview makerhub linx has a built in error checking process with packets sent and received that slows down the loop speed. So one way to speed it up is to reduce the latency timer in the  device manager as shown below.  

[JColvin]

Depending on how your code is set up, you could also create what is known as a custom command in LINX. There is a Forum thread that walks through how to make one here as well as some documentation from LabVIEW MakerHub on it here.

The idea behind a custom command is that LabVIEW (LINX) would send out a single command (realistically this will still be 5 bytes or so thanks to the packet checking), but then all of the operations will be done on the system board (WF32, Raspberry Pi, etc) based on a function that runs through the procedure once it receives the command packet from LabVIEW. This helps prevent LabVIEW needing to send out multiple commands of read this pin, process this, send out this, process again, etc, and can just have the microcontroller do all of the processing at it's own faster pace and then send the result back to LabVIEW when it is finished. If you have a lot of back and forth between LabVIEW and the MCU, this can definitely speed up the loop rate by merit of simply not communicating as often.

The drawback with this is you'll have to do error testing and debugging on the microcontroller side rather than being able to do everything within a single environment, but you do get to potentially (again, depends on your application setup) speed up your loop rate.

I guess as a side note, you are not able to port your LabVIEW VI to the chipKIT boards like you are with the BBB and RPi's at this point in time (as you noted) so there isn't a nice way to get those sort of speeds as far as I know. Hopefully that will be able to be done in the future, but I'm not privy towards those sort of developments.

Thanks,
JColvin

[Craig Cloud]

@jpeyron @JColvin thanks for your help.  Will give it a try.  I know C# but maybe its time I learned C.