We like to communicate with a new device by using a SNAP-SCM-232 module, this is complete new for us and there for I look for some help in how to configure and how to set up the communication.
the software we use is Snap Project prof. 9.6.
Our hardware setup is, controller S2 is connected to two racks both with a R1 controller, on the first rack we have installed the SNAP-SCM-232 module this is connected to the device.
Who can help me on setting up the configuration and provide us with example of a communication protocol with the device
I already have studied the userās guide form 1191.
@Peter_de_Koning How did you go? Were those posts helpful? Are you up and running?
Lets know if you have any other questions or if you have some specific feedback on that forum post from Mary.
making not much progress, this is the first time we use RS 232 communication, so there for I takes some time to understand how to get the communications started.
The module is installed and we use the standard conf. so no need to change this.
but how to send and receive a command?
i think:
SendCommunicationHandleCommand(tcp:146.30.101.143:22518, " ASEM");
GetCommunicationHandleValue(tcp:146.30.101.143:22518, ā ASEM 0 5 ā¦ā¦enz ā);
we need to use the AK protocol there for we use ā¦.
I my thinking right?
some examples will be very helpful. I need also a smart way how to build up comm handle and strip them to get my values.
AK protocol, is the protocol for the apparatus I need to communicate with, its a German apparatus
You say you have the serial module commands set, so that is a good start.
Next you need to find out if there are any characters that have come in on the serial port;
In my case, I just needed to know if there were 2 or more characters waiting. You may need more to be sure you got the whole string you want.
The incoming characters are held in a buffer, so we simply are seeing how many characters are in the buffer.
Once you are sure you have have enough characters waiting, you can then go and empty the buffer and move the characters into a string; rx_string_status = ReceiveString(rx_string,chTCP);
Thatās it really. You now have the buffer in the string and you can start looking for your data with the string commands.
The summery of commands is under the communications category;
I took a look at the AK protocol and this is a request/response type protocol. Bens code is good for reading from devices that transmit on their own, but is not what you need to talk to your instrument.
Here is something that should get you started. I havenāt tested this, as I donāt have the hardware that you have. You also need to check for error codes and add what ever logic you need to trigger the communications when you need to. This is setup to retrieve the serial # of the instrument.
//commHandle is a variable in PAC Control of type communication handle.
//You should already have configure the serial module through PAC Manager for the baud rate, stop bit, and parity (9600 8n1).
//This should be set one time (in your powerup maybe), or can be setup as the initial value when you create the variable
SetCommunicationHandleValue("tcp:146.30.101.143:22518", commHandle);
//Initialize some protocol constants, only need to do this once
sSTX = Chr(2);
sETX = Chr(3);
//Here is some code to send a command and parse the response
//You will want to add additional logic to this for error handling and so forth
if (GetNumCharsWaiting(commHandle) < 0 or not IsCommunicationOpen(commHandle)) then
nResult = OpenOutgoingCommunication(commHandle);
SetEndOfMessageTerminator(commHandle, 3); //ASCII 3 per protocol
else
ClearCommunicationReceiveBuffer(commHandle);
endif
//Build a command - I'm going to use some variables to make this easier
//That way you can just change the following values for other commands
sFunction = "AKEN";
sChannel = "2";
sParameters = "";
//Put the above command together into a request to send out the port
sRequest = sSTX + "_" + sFunction + " K" + sChannel + " " + sParameters + sETX;
//This is a built in fucntion that makes it easy for command/response type protocols
nResult = TransmitReceiveString(sRequest, commHandle, sResponse);
//SHOULD check nResult here for errors
//Parse response
//Find the end of the string where the ETX is (could also use string length since it should
//always be the last character
nEndPos = FindCharacterInString(3, 0, sResponse);
//Grab the payload starting at byte 10 (index 9) to the ETX according to the protocol
//sPayload should have the response to the command.
GetSubstring(sResponse, 9, nEndPos - 9, sPayload);
thank you for your response, very helpful I think I begin to understand the script.
I have a questions:
why do you need to initialize these?
sSTX = Chr(2);
sETX = Chr(3);
In this command you close the comm handle?
"SetEndOfMessageTerminator(commHandle, 3); //ASCII 3 per protocol "
but I donāt see you open the comm handle do I miss understand the script?
do you have more script code, I need to handle errors for example.
We canāt give you all the code you need as we do not have your serial devices here.
If you want to check for errors, then look at the status of nResult. The PAC Control users guide has the possible error values that it might have, handle each as you see fit.
Just for convenience. You could put Chr(2) directly in the Request payload, but using a variable is much more clear.
Read the documentation on that command and it will be more clear. The responses from your device are terminated with an ASCII 3 character. That command tells the TransmitReceiveString command to wait for that character in the response and then return it.
You will need to decide what you need to do to handle comm errors. Typically you close the connection, wait for a delay period and try again. It all depends on your process, device, and goals.
Iām happy to answer any questions you have as time permits, but If you would like integration work send me a private message and we can work something out.
