labview pid control ball balance

[JCG77]

Hi everyone,

The past couple weeks I've been working on a project and I've gotten lots fo great help for which I'm very appreciative for as a new user to LabVIEW and myRIO. I'm at the point now where I'm finally tying everything together for my main control VI.

This Youtube video shows what it is I'm trying to recreate: https://www.youtube.com/watch?v=FBy_e4yvqhQ. 

I have attached a picture of what I have so far. You can see I've got a touchscreen which is feeding serial data to the myRIO.

My main VI  (Main Check 2) is composed of two parts: the motor control part and the touchscreen reading part. The motor control part consists mostly of a PID controller while the touchscreen reading part takes serial data from the touchscreen in as hexidecimal values and converts them to milimeter coordinates on the screen. 

Each part, the motor control part and the touchscren read part appear to operate well on their own as seperate VIs. Only, when I join the two together, they don't perform at all. 

Would anybody happen to have any suggestions on how get my main VI working?

Thank you kindly,

James

[JCG77]

Just a little bit of context for the touchscreen reading part of the VI. 10 bytes of hexidecimal data comes in the serial port of the myRIO. The hex string starts with 5554, so we're trying to read each string starting with these two bytes. 

[JCG77]

Sorry, Main Check 2 is the wrong VI. I've attached the right one.

[NapDynamite]

Could you post a snapshot of the program's block diagram? 

Regards.

[JCG77]

Hey,

Thank you for your reply. The block diagram is a bit big to take a screen capture but I've uploaded it as a LabVIEW 2014 file. 

[NapDynamite]

Looking at the code I couldn't grab what's wrong since it's too cluttered. Though I have noticed few things:

1. You have a VISA resource constant and Serial configuration (baud rate, flow control constant) wired and placed inside the while loop. You don't need to do that. Just initialize it at the beginning of execution by putting it outside the main loop.

2. LabVIEW is known for data flow, make sure you wire the error wires to make parts of your code sequential where you want it to be. 

3. Why don't you use subVIs to make your code mess-free?

Few things yo need to do before we can provide a specific solution:

1. While running your main program, does the LabVIEW generates an error? If yes, then what is it?

2. If No, have you tried tracing/ debugging your code by turning "highlight execution" on?

LabVIEW doesn't appreciate "grabbing" and "throwing" data using a single loop. We have outstanding techniques for that. Use "producer/consumer loop" technique if you are using a PC to run and monitor your system. This way you can "grab" serial data from touch panel in one loop and "process/throw" data to actuators and front panel in the other loop.  Or use "queued state machine" if you're deploying it inside myRIO as a standalone application. 

Below are few resources to get you going.

https://decibel.ni.com/content/docs/DOC-32964

https://decibel.ni.com/content/docs/DOC-14169

http://www.ni.com/white-paper/3023/en/

There's also a labVIEW template for machine vision application. I am sure you can modify it to your needs. It's a great template working on Queued State Architecture.

[JCG77]

Thank you for your help.

I tried using the consumer/produce data template for LabVIEW. I can't quite seem to get it to work.

We have the touchscreen passing data to the myRIO. We know the first two bytes in a string of data we need are 55 and 54. We're trying to filter out data that begins with these two bytes and let the other serial data pass through and not be queued. 

I've uploaded the new version of the VI as well as a version for 2014 users as well as a version utilizing subVIs to make reading the program easier. 

Thank you again for your help. 

[JCG77]

I think I've almost got it here. I can now read the numbers I need to read for the serial data and my PWM outputs to the servo motors are somewhat working. Only my motors don't respond the way they're supposed to. Each time a new input comes into the consumer loop my motors will pulse.

I've uploaded my latest work.