Modbus Poll is a Modbus master simulator designed primarily to help developers of Modbus slave devices or others that want to test and simulate the Modbus protocol. With the multiple document interface you can monitor several Modbus slaves and/or data areas at the same time. For each window you simply specify the Modbus slave ID, function, address, size and poll rate. You can read and write registers and coils from any window. If you want to change a single register, simply double click the value. Or you can change multiple registers/coils. Multiple data formats such as float, double and long with word order swapping are available.
OLE Automation for interfacing with Excel. To interpret and show the Modbus data according to your specific requirements. E.g. edit data in Excel and then transmit the data to your slave device! Try the Excel example.xlsm installed with the program.
I am trying to do the exact same thing that I do in Modbus Poll in labview to get a connection with a modbus device. There are different connection setup data to be selected. I have attached the a pic of the modbus poll connection setup.
One of the content here as you can see is the delay between polls. But in LabVIEW while making a modbus connection, I cannot find that option. All the other stuff such as type of connection, serial settings like baudrate, data bits, parity, stop bit and timoeout can be found in labview but not delay between polls. Can anyone help me find out how I can set that data. Thank you.
Like the comments before, you are the one making the requests (the polls), if you need to make continuous reads you would need a loop (for or while, it depends what is the task you are trying to solve) and a timer between each iteration (this would be your Delay between polls), but if you want a similar configuration panel for the user of the software you are writing, you need to provide the control used as input to your timer.
Maybe you can start step by step. First disable the related things in Main UI. then start bottom up to activate them and have a look at the log entries written. Do this bottom-up (Bridge-, Poller-, Data-Thing).
Post these parts of the log as well.
As this is device dependent and we do not even know about the hardware dealt with (nor the modbus registers available or the data to be read) Chris should provide his setup.
Makes no sense if e.g. I would post my setup for a certain energy meter or a relais board when the intention is to e.g. read values from a solar inverter.
So @2mad4max , kindly give us some insights and we can solve the mystery.
I tried to get a modbus register map for your device, but I did not find it a the Schneid website.
What is crucial with modbus is to know the format of the data to be read. E.g; An Integer could be 16, 32 or 64bit, it might be a signed or unsigned value. ModBus is somehow old and usually is based on 16 bit words that are combined to larger data types by reading multiple words and interpreting the result (signed/unsigend, number of digits/fraction)
My energy meter provides the total avtive import as 64 bit unsigned value, so you need to read 4 16bit words. It is important to set the correct read value type when reading data.
image1450224 11.2 KB
(Sorry this shows a different (signed) value than in the example below)
The register map provided by the vendor is the most important part, there you see how data is provided / structured.
Your bridges look OK (btw: standard port for modbus is 502 (You use 2000, but that is your choice).
Do you have a link to the documentation of the modbus register map?
I guess that the data things are not correctly mapped to the data type in OH.
When I use function code 03, TxD and RxD on Moxa connector are blinking, but only RxD is blinking on CM1241, and I receive error "Checksum error" when trying to write on only one address. Or "Insufficient bytes received" when trying to read from more then one address.
only my opinion, if your info about 2 PLCs connected together was functional, I see problem probably in MB poll SW or Moxa adapter. I must say, I had one of this adapters (older type one) and was not satisfied with it's functionality, next Moxa adapters/converters (like NPort) are ok in my opinion, but this can be personal opinion. I don't know that MB poll SW functionality, so don't know if someone will answer exactly what problem can be, maybe with parameter of requested address of register (some SWs use offset/ some not), maybe also max amount requested data (also must be checked in your DB if are sufficient). Hope you'll find problem so soon, good luck.
Duris thank you for your answer.
That is also my opinion, if 2 PLCs (Master and Slave) communicate throught MODBUS connection it shouldn't be a problem that other devices communicate with Slave.
But, I still didn't find what is the problem.
I tried with another software (Simply Modbus Master) but with no success.
I can not believe that nobody here didn't try to test Siemens PLCs Modbus communication with some software from PC.
I am running out of ideas what to do, stuck with this for a week already.
I'm curious how you did that test with app from SimplyModbus. Simply if you send some request from PLC to Slave PC app (f.ex. simplymodbus RTU Slave), you must see in app error message or something depended to request. If you can, make again one test and post screenshot from Slave RTU app simply modbus, not that other SW (I don't know it's functionality). Look carefully to TX/RX lights of your CM module and also to Moxa's LEDs. You can also omit these MB SWs and connect simple Hyperterminal and after recv check incoming message consistency (also you can attach screenshot with of course description what you request from PLC - can be quickly checked). Simply you must try more options, no other way.
look to www.simplymodbus.ca for byte sequence description, also you have that in SW. Look, logically 20 bytes are only your needed 10 values but MB complete message must also include other needed informations that are described in help. Pay attention to not manipulate with standard settings in PC SW (offsets) if you don't know really what you do. This can be not easy then recreate back to functional state.
Hi again,
sorry for not posting earlier, I was on the field last few days so I couldn't answer earlier.
Regarding address, that is not the problem. Just print screen taken in wrong moment.
I have error 16#80E2 (Frame aborted: Character frame error Check the settings for start bit, data bits, parity bit, data transmission rate, and stop bit(s).) so I tried to change something of this to make thing work but with no results.
In attachment there are new picture with marked settings on PLC and on PC.
I really don't see what is the problem.
Is there anyone with PLC program tested with some PC software for MODBUS testing that is working?
I have also repeatedly verified just now that T3-BB TB-LB is able to access a third-party device normally by connecting it to a third-party device in the RS485-Sub Port and using the connection shown below. ()
Please Update T3000 again . Version : Jan 6 2021 . 14
Fixed a bug where the T3000 Modbus Poll established a TCP connection with the server and the connection was disconnected by the server, causing the communication to be unable to continue.
Updated with the latest T3000 version (.14): OK
tried to poll modbus unit: failed
will install another 3rd party modbus device instead of my unit to see if the problem is consistent
thank you for your time
However, after few minutes, spontaneously, the setting of the sub network of my T3-LB, while polling, is going from master to slave and the poll stops.Firmware 54.4 and latest T3000
Any idea ?
Update: switched modbus networks: set sub rs485 as unused and set main rs485 as master and will see how it behaves. feedback on this later.
Nope, test finished: same problem, the rs485 switches always from master to slave and stops communication with my 3rd party device.
I am trying to implement MODBUS RTU with serial communication, without using modbus libraries. I have Arduino uno configured as slave and MODBUS poll software as master. Its a small code. I have slave id, function code and data stored in EEPROM.
As suggested by you, I have implemented CRC and it is calculating proper CRC. However, when I am doing communication through MODBUS poll, it shows "insufficient bytes received" error message.
Looking at your code, the higher byte of the calculated CRC in your sendResp[] buffer will always be zero. This is because you defined sendResp[] as type char (i.e. 8 bits). When you AND your CRC with 0xFF00, you need to shift the result right 8 bits first before putting it in your sendResp[] buffer. As it is, you are simply storing the lower 8 bits, which, as a result of the AND, will always be 0x00.
Now I have written Modbus Master code to extend the functionality. Here is how I want my test project to work, "There are two Arduino Uno devices. One should be configured as master and other as slave. Master will request 5 register data from slave and print on serial terminal."
As you are using straight forward serial data, it can be a useful debugging aid if you have a spare TTL->USB serial converter. You can connect its GND to your Arduino GND and its RX to your master TX line on the Arduino. You can then use a PC terminal program to view the actual bytes being transmitted as it happens. If you have 2 TTL->USB serial converters, you can listen in to both sides of the conversation at the same time.
The purpose of adding 0's in sendReq[0]-sendReq[3] is that the document says, "For master to initiate communication, there should be at least 3.5 characters silent bits. And same should be at the trailing end so that the receiver can know when the frame ended."
05f2edc126