Created Date: June 30,2014

Created by: scott.lawrence

have you downloaded the Solo software?

http://www.automationdirect.com/adc/Shopping/Catalog/Process_Control_-a-_Measurement/Temperature_-z-_Process_Controllers/Spare_Parts_-a-_Accessories/SL-SOFT

can you communicate with the controller using the software? Are you using RS-485? IS the controller itself set for RTU or ASCII?

Created Date: June 30,2014

Created by: Esky

Yes. I can connect, configure, record readings etc. via the SOLO Software, but I want to be able to get the process values via my custom app so that I can conveniently store them in a database as well as display the readings on a remote terminal.

Per the MODBUS ASCII protocol (unless I am misunderstanding something), for a function 03 read request, 17 bytes are required... one byte (colon), 2 bytes for the address, 2 bytes for the function, 4 bytes for the starting register, 4 bytes for the quantity of registers to read, 2 bytes for LRC, 2 bytes for CRLF. The SOLO manual shows the process value register address as 1000 hex, 44097 MODBUS decimal, and V10000 PLC Address octal. Since I am reading the register, the MODBUS 44097 should be used. The 4xxxxx is understood, so now I am only referencing the 4097 starting register.

I have read from some sources that some controllers do not strictly follow the MODBUS protocol because their number of registers exceeds that for which the protocol was originally written. I have a feeling that the SOLO controls are not strictly following the protocol. Why isn't detailed information provided in the SOLO manual regarding the framing that is needed to communicate via MODBUS? The manual simply gives the registers ' addresses.

Created Date: June 30,2014

Created by: ControlsGuy

Expecting them to document Modbus in the manual doesn't make sense. That's the point of there being a standard, so that in theory you already know how to use the protocol without ever having seen the slave device. Personally, I HATE devices that document standard Modbus in the device manual, because it implies there's something non-standard about their implementation. Last year, for example, I was trying to talk to a servo whose Modbus documentation talked about sending the value 0xFF00 to set a bit. I'm scratching my head wondering what they 're up to, and it turns out that's the standard way of setting a bit in Modbus (my experience dealing with Modbus at a comm-byte level had been limited before that to integers, double integers, and floats).

IMO, documenting register mapping and no more than that is exactly the correct approach.

As far as exceeding the number of registers Modbus was designed for, I have no idea what that would be about. Modbus slaves can have tens of thousands of accessible registers. I have one that has 50K (and the two byte register address allows for up to 64K), so I guarantee you a temp controller is never going to have more registers than Modbus can access. Even many PLC's don't. Now a given transaction is limited to slightly less than 256 bytes, so you 're only going to get maybe 125 ints or 63 floats or DINTs or so max per read, but that has nothing to do with transactions failing.

Seriously, try using a PC-based Modbus utility, to determine if the problem is in your master or maybe the Solo unit has a problem. There are many, and a lot of them are free

Also, why use ASCII when there's RTU? Do the Solos not support RTU? Does a human need to be able to read the stream in real time?

Created Date: July 02,2014

Created by: Esky

I disagree. A proper manual should be written as though the user is new to the device/system and provide a quick reference or brief example(s) to get a new user up and running quickly without the need for the user to reference other multiple resources. If experienced users do not wish to see the examples, they do not need to read the appendices. Most manuals are distributed electronically so having an extra page or two should not matter.

In any case, I ended up running a serial port sniffer program ( http://www.serialmon.com/ ) so that I could see the interaction between the SOLO program and the controller. By doing so I realized that my LRC algorithm was incorrect. I thought that (according to the MODBUS protocol) if the LRC is incorrect the device is to ignore the command. This device was returning an error code for the function instead.

I may post my code when I'm done so that others that are new to communicating with the SOLO controllers have an easier time.

Created Date: June 27,2014

Created by: Esky

I am getting an exception error (83 03) when trying to read the process value from the SOLO 9696. I am not sure what is wrong though. It may be the PV register number, but I think the exception 03 means the number of registers are wrong (?). Any help would be appreciated.

Controller address is 01. Function is 03. Starting address for PV is 1000 (hex). Number of registers to query is 0001. LRC is FA. Close with CRLF.

SENDING 3A 0 1 0 3 1 0 0 0 0 0 0 1 F A D A (17 bytes)

RECEIVING 3A 01 38 33 30 33 37 39 D A 0 (11 bytes)

In Ascii, the reply echoes the address (01), then gives 83 (error code) and 03 (exception code) followed by 79 (LRC).

Page 7-3 of the SOLO manual does show a Modbus decimal value of 44097 for the process value register, which I believe is supposed to be 40,000 more than the hex value (1000) or 4096 decimal, but I am not sure where the extra 1 is coming from. Nor do I know how to use the Modbus decimal value in the command that is being sent.