Arduino Microcontroller TTL C++ Code (Master / Slave Communication)

The purpose of this code is to be able to send a command through Arduino C++ code to a slave device over Serial1 then have the master read back the returned values from the slave whenever it sends out a query (for further processing outside the scope of this project) but it should also optionally be able to display the Tx and Rx commands over Serial so it can be reviewed through the Arduino Serial Monitor. Note that the data is ultimately being sent through a RS485 device but that hardware is responsible for taking the TTL serial output and converting it both ways (so this code does not need to handle that). The Tx and Rx data will always be in the format of a single message is sent (Tx) and a single message is returned back (Rx). To send and receive a command, here is an example of working code. You do not need to use this exact method but it does show the message being sent and has been tested working. byte message [] = {0x01, 0x01, 0x09, 0x02, 0x00, 0x02, 0x02, 0x02, 0x20, 0x0B, 0x20, 0x00, 0x04}; [login to view URL](message, sizeof(message)); Which will send (Tx) the hex digits 01 01 09 02 00 02 02 02 20 0B 20 00 04. Please see the attachment for a visual example of the message format. The first value, 0x01 represents the Start Header. The fourth value, 0x02 represents the Start Data 0. The final value, 0x04 represents the Checksum. Those values and their location will never change in a Tx (or Rx for that matter) message. The second value, 0x01 represents the slave ID that this is being sent to. That will change but if the master is sending a command to 0x01, only 0x01 will respond and that value will always be 0x01 in that case. The 0x02 slave will never respond to a message sent to the 0x01 slave for example. Assuming the 0x01 slave unit is in a good operational state, the slave with an ID of 01 will respond (Rx) to the above message with: 01 01 0C 02 00 00 00 37 28 A2 08 5A 9D 24 00 04 Please see the attached image for a further breakdown of what this Rx message means. #1, 01 represents the Start Header. #2, 01 represents the slave ID. #3, 09 represents the lenght (in hex) so 9 in this case, a total length of 13 because no CRC and the Start Header, the ID, the Length and the End Telegram are not counted here. #4, 02 always indicates that this is Start Data 0. #5, 00 Motion Control Sub ID - This is where the actual message starts and will differ often. This is sub ID (00 in this case) #6, 02 Motion Control Main ID - this represents Write Motion Control Interface but that doesn't matter too much here except to represent the next value, the count, which needs to differ slightly from message to message. #7, 02 this is the count, which needs to change each time a Write Motion Control Tx message is sent (it can go from 01 to 02 and back to 01 or it can go from 01 to 02 and continue to 0F before wrapping back to 01 but when using the Write Motion Control Interface as selected by sending 00 #8, 02 above, the count needs to be different with each Tx that sends a Write Motion Control message. #9, 02 This is the Motion Cmd Intf Header High Byte Master ID =2 and can stay 02. #10, 20 Target position movement lowest byte #11, 0B Target position movement middle low byte #12, 20 Target position movement middle high byte #13, 00 Target position movement highest byte - so this and the prior 3 values (20 0B 20 00) represent this message telling the slave to move to the following location that is mapped to those 4 values. In this case, it maps out to 0x200B20, the desired value. #14, 04 is the End Telegram and will always be the last value of a Tx or Rx message even if a checksum is used. In this case, the purpose of this message is to send a command to the 01 slave to move to the 0x200B20 position. The slave responds and indicates it has received the command, has heard it and reiterates what it is doing (where it is now going to) and what state it is currently in. Please review the complete requirements file (attached).