controlling pressure using valve and pressure transducer

[mjacsouza]

the system has a pressure relief valve on it for safety measures.

[mjacsouza]

- I do know the difference between mean and median. Median is the middle of the total numbers if the numbers were lined up consecutively. Mean is the sum of the numbers divided by the amount of numbers there are. 

-The BytesAtPort is there to give me a general idea of which way the valve is moving. towards 90 degrees or towards 0. It was more of a troubleshooting aid. 

-rounding the pressure reading to an integer number gave me more stable comparisons when i was trying to compare the value with the set point, but i took  the comparisons out. So ultimately it doesn't make sense to leave in.

- I do not know the complete influence of such "signals with steps" on PID controllers. That is part of the reason I am asking these questions.

- I determined the PID gains by watching the valve move when i changed the set point below atmospheric pressure and above atmospheric pressure. So they were determined experimentally.

- I haven't determined the influence of the vacuum pump on the control loop. The chamber I am attempting to maintain a set point pressure is small (it has a pressure relief valve if anyone was wondering so the pressure wont get above 1000 Torr) So the pressure changes are very quick.

- I appreciate you answering me but I also want to say I came here to learn and get help when needed. If anyone is willing be helpful it would be very welcomed. Thank you.

[RavensFan]

---

@mjacsouza wrote:

-The BytesAtPort is there to give me a general idea of which way the valve is moving. towards 90 degrees or towards 0. It was more of a troubleshooting aid. 

---

That doesn't make any sense.  Bytes at Port tells you how many bytes have arrived at a serial port.  It tells you nothing about the valve.

Using Bytes at Port is wrong about 99% of the time.  It definitely won't work in your VI.  You write a command, then immediately ask for the number of bytes at port.  Guess what?  It will probably be zero because you didn't give the device enough time to react to your command and return a response.  You'll wind up reading 0 bytes.  Now later on, you will send another write command, but you might finally have some bytes to read that is the response to the previous command.

What else is odd is that you send a second command for ang, but you never bother to read its response, at least not until it gets pushed in with the pos command and gets read in one shot.

If you ever think you should use Bytes at Port, don't.  If you still think you do, then make sure you read the manual and understand the communication protocol, because, as I said, 99% of the time you won't need Bytes at Port.

Your Serial Configure is set to use a termination character of a line feed by default.  So assuming that is correct for your device, you should be using that.  You just need to read a number of bytes that is larger than the longest response you expect to receive.

[mjacsouza]

RavensFan do you mean something like this 

[GerdW]

Hi mjacsouza,

no, not at all!

Read the help for the SerialPortInit function: here you enabled and selected the TermChar (by using default values).

For the VISARead you only need to wire a numeric constant with a value larger than the expected number of bytes per message. (I usually use "99"…)

Btw. You really should cleanup your block diagram before posting images of it: there are hidden wires and we cannot see which wire sink is connected to which wire source…

[mjacsouza]

So if the longest number of bytes read is 4 then i can just hard code in a 5 into the visa read. 

[RavensFan]

Yes.  But you might as well make it 100, or 1000.

As Gerd said, don't use that property node, just wire in the appropriate values in the VISA Serial Configure function.  If nothing is wired up, you'll get the defaults of termination character enabled and the character as a linefeed. (ASCII 10 (or x0A)).