Data Transfer

[jwbaker3]

I need to get barcode information from the clients computer system into the BRX plc . I am currently we are using a scanner to read a QR code that I link to the process and transfer the information to the clients computer system via FTPPUT thru his FTP server in CSV format when the process is complete. Would it be better to use FTPGET or set up a MQTT broker on his computer and use JSON or something else? The system will cycle a new part into the system every 3 minutes so not really fast, speed should not be an issue with any system. Suggestions on these or something better, we are open to what will work the best.

Thanks,
JW

[jwbaker3]

AD Tech support said I could not send data to the BRX by REST API only sent data out. Is there options other than FTP & MQTT to get data from a PC into the BRX? String or text. The customer wanted to use REST API, I like MQTT better but they don't want to setup a broker so we are looking for other options.

Thanks,
JW

[Greg]

...Is there options other than FTP & MQTT to get data from a PC into the BRX? String or text...

There are multiple ways to do this and it all will depend on what you can make your PC do. Will the PC be the client (initiator) or the server (responder)?

• Modbus TCP: If PC is client, it could send the ASCII data via Modbus TCP to the BRX's M-memory (e.g. MIR or MHR), and then you could decode that data in the BRX and put it in a string.
• Modbus TCP: If PC is server, the BRX could put string data into M-memory (MIR or MHR), and the PC's Modbus TCP client could read it out, and parse it.
• HTTP: The BRX is capable of using HTTP PUT/GET commands, if your PC is able to utilize those.
• FTP: You could put the string data in a file, and FTP it.
• Ethernet/IP (client/server): You could use the EIPMSG instruction in the BRX and read/write data from/to the PC, or setup the BRX using Ethernet/IP server, and allow the PC to read/write data to the BRX.
• Custom UDP/IP: You could read/write data from/to the BRX on a UDP port and use PACKETIN/PACKETOUT instructions
• Custom TCP/IP: You could read/write data from/to the BRX using TCP and utilize the TCP-instructions (STREAMIN/STREAMOUT).

Just some ideas. All these ideas you can find the details in the Help file of Do-more Designer.

[franji1]

As you can see, Do-more is a Comm Beast.

The choices are many.  Does the QR code contain ALL the information, or is it just a KEY that the PC then has to look up for the PLC?  If it contains ALL the information, especially if it's in JSON form, you could connect it to the PLC directly and eliminate the PC?

If the PC is necessary for providing more info than just what's on the QR code, JSON is a good human-readable form that Do-more and PCs can parse/generate.  A custom UDP or TCP protocol would be easy to implement on the PLC side, but the PC side code would be up to you to write.

A simple Stage program waiting for a packet (PACKETIN) or listening on a TCP port (TCPLISTEN) would be the "initial stage", waiting for that data from the PC.  Once you get the JSON packet, JSONPARSE calls can get it in a non-ASCII form that the PLC better can handle.  A simple ACK or data response would  follow the parsing, then EXIT the stage program and immediately RUN the program again to wait on the next barcode.

If you've never written comm protocols on the PC side, you would be better off doing something like Modbus - there's plenty of Modbus Master code out there where the PLC would be the slave.  You could still send large amounts of ASCII JSON data via Modbus (e.g. write all the data to MHR101 and up (40101), then write the Length to MHR100 (40100) - that would kick off the code in the PLC (when MHR100 changes from 0 to non-zero).  Parse the data, clear MHR100 and wait for the next barcode via Modbus.

You could have Do-more be the Master and constantly POLL the PC via Modbus - I don't like those kinds of solutions, but it's also do-able.

JSONPARSE supports numeric blocks like MHR cast as BYTEs (e.g. text starts at MHR101:UB0), so human readable JSON as the data format is good.  Designer has a JSON Pretty Print that pretty's up the text in a JSON record - it puts a CR at every bracket, indents at every nested bracket, even pastel-colorizes fields/data at the same nest level.  You could do raw binary data transfers using Modbus, but that's a little harder to parse if it's not a simple flat record where everything is on a WORD boundary (e.g. all records are the same - 16 bits attributes, WORD recipe #, REAL weight, WORD cook temperature, 16 bits attribute2, ...).  JSON has more overhead (field names in addition to the data, which is all in text form that must be parsed), but it's much more human readable.  JSON extends more easily also (add new fields, or even nest new objects); also your JSONPARSE logic can ignore fields (e.g. don't care about field XYZZY that's in the QRcode).

[jwbaker3]

Franji1,

Thanks for all of the suggestions they are using a program on their PC system to schedule production. I am not sure if it is homegrown or not but they are trying to find a way to send data from it.

I sent them all of the information on the BRX comm's it up to their IT guys to get it working.

Again, thanks for taking the time to get me the information and suggestions.

Thanks
JW