Hi!
I’m trying to send a list of bytes to a device via MODBUS TCP/IP to query its data.
The device accepts a structure of 11 bytes in hexadecimal format, comprising of IDs, function codes, size of structure, etc.
I’ve looked through the URScript manual and it seems that ‘socket_send_byte’ is the closest one I need for this application. Hence I’ve made 11 lines of ‘socket_send_byte(x)’ where x can be the function code, ID, etc, however I did not get the intended results on PolyScope.
However, I managed to get the intended results using Python, by converting a hexa string to bytes before sending it to the device : b’\x00\x00\x00\x00\x00\x06\xFF\x03\x00\x00\x00\x01’.
If socket_send_byte(x) is indeed the function I should use on URScript, should my x be the value that represents the ASCII equivalent (egs x = 48 to represent 0) or should it be decimal? If it’s ASCII, is there any way to represent the special character of the hexa ‘FF’?
I’d appreciate your advice!
As documented in the URScript manual, the value-parameter of socket_send_byte() is the integer value of the ASCII byte.
I.e. integer 10 will give the LF character, while 65 is ‘A’.
However there already is a Modbus TCP interface in URScript.
Any reason why this cannot be used?
Thanks for your reply!
By ‘modbus tcp’ interface, do you mean functions like ‘modbus_add_signal’, ‘modbus_get_signal_status’ ?
I forgot to mention that the device I was mentioning about is a set of an RFID reader and tag.
I’ve tried using the functions mentioned above. However, the program stops due to exceptions being created when the program tries to execute ‘modbus_get_signal_status’ when the tag is not present (not at reading range). However, we are able to read the value registered in the tag ONLY when the tag is in reading range (tag present) BEFORE the program is run (or when it gets to the line where it executes ‘modbus_get_signal_status’).
I’ve managed to find a workaround for this: executing the function only when a certain condition is met (egs. when we know the tag is in reading range based on a signal (high/low) by another sensor like a proximity sensor).
I was wondering if there is a more elegant solution to this or it is the nature of RFID readers that causes these limitations.