LabVIEW
How can I create a labview interface to control a MKS946 vacuum system controller?
Hi John,
Regarding the serial communication and switched lines, the manual states that pin 2 is Transmit (TxD) and 3 is Receive, which I think is the normal behaviour. If your cable isn't working, you could try something like this: Monotaro shop link - Null Modem Adapter (obviously you can find these from other stores, this was the first link I saw on a Google search for "null modem adapter db9" (incidentally, the connection isn't actually DB9, but it's commonly mislabelled in that way)).
I suspect you might still have software issues though, so maybe before buying more hardware, you could try creating some (sub)VIs that handle specific commands and their formatting. That way, we could give hints on the string formatting etc.
Based on your images, I think you might not have the message format quite right.
As a quick test, I'd suggest using the example string they give on p96 - "@003PR1?;FF" to which the response should be something like "@003ACK7.602E+2;FF", where the 7.602E+2 will vary.
It doesn't appear that you have a TermChar, so you'll want to disable those options on the configuration. This is a frustration when trying to setup this kind of communication, but not impossible to work around.
Edit: I forgot to mention, and I don't think it's been confirmed yet, but as you suspected, if you don't need the command for programmatic control, you don't need to program it! (This would probably be a problem if you were creating a device driver you wanted to publish, but if it's only for your use in your workplace etc, no need to code up all the functions you're not using).
John,
First off, I would use a high-quality serial adapter to give yourself more options and less hassle in the future. I usually use MOXA devices like the 1000 series for USB or the IA5450AI or similar to connect over Ethernet. They have proven to be very robust. It's not worth messing around trying to save a buck at the expense of your time and delaying a project.
Generally, the RS-232 port on a computer (or USB adapter) is a Male 9-pin connector with Tx on Pin 2 and Rx on Pin 3. The MKS datasheet states Pin 2 is Tx and 3 is Rx. Therefore, you must swap the pins with a null modem adapter or null modem cable (usually marked "NULL" on the ends). To clarify, the PC's Tx must go to the device's Rx, and the PC's Rx must go to the device's Tx. When one talks, the other must listen.
The chapter 8/9 issue is a massive typo in the MKS document. Looks like they meant to split 8.5-8.19 into its own chapter. Not sure how they generated a new table of contents without the headings changing. Maybe it's the other way around and they didn't rebuild the table. Either way: oops.
I do this stuff daily, and if I were you I would start with the fixed up example from @Albert.Geven and add event cases for every feature you would like to implement. Here's an example of an MKS 947B controller interface I made a while back:
As @cbutcher noted, most commands are not necessary to implement for this controller. You can manually set up the controller the first time using its physical front panel. Later on, you basically only need to read the status and control channel enables. CPn is the only command I ever send (to turn a channel on or off). Otherwise, it's status polling using PRZ in the Timeout case. The timeout value should probably be 500~2000 ms, as the pressures generally don't change quickly (and the response time of the sensors is not that high anyway).
You can create a general-purpose vi for forming the particular command you'd like to send:
As you can see, I've made a type def'd enum out of all valid commands to send to the controller. Internally, the vi formats the command string appropriately for each message type. The vi for other commands might have other input terminals with information required to build the string. Then you do your serial Tx/Rx, and then separately parse the response based on the message you sent. (Note I'm doing serial over TCP here using a MOXA serial server.) This makes a clean, modular top level that is easily extended to support more commands.
Sorry, I can't attach the code, but this should give you an idea of one way to approach this. Hope it helps!
That error is reporting that the port is being used by some other application/user.
You might have the VISA Test Panel still open? Or have a problem with the port remaining open (although the VI looks to close it properly).
Only one application can communicate with the COM port at a given time - if one has the connection open then (at least the VISA driver) won't let other applications use it.
(For perhaps related information, see https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Sharing-VISA-Resources-With-Multiple-Applica...)
First off, the event structure does not have its timeout value input wired, so your Timeout event case never executes. Change that to a Read button click event if you want to read a specific number of bytes (as you are doing). Otherwise, use the Bytes at Port property to periodically read from the port. I'd also make the Write a button instead of making it on-change of the command string.
Note Timeout value of 100 ms. VISA Read only if the number of bytes is >0 (not shown).
As @cbutcher already stated, the port can only be opened in one place at a time, so be sure to gracefully close the port and do not use the "Abort Execution" button as it will hang the serial port.
