Unzip the compressed files into a common folder on your hard drive.
Simply Modbus Master 6.4.1.exe - the program
serpdrv - serial port driver
Read me Slave 2.1.txt - documentation
Read me for Windows7.txt - documentation
Known Issues with version 6.4.1: Two instances normally appears in the taskbar while the program is running, the runtime engine and the program itself, Sometimes the runtime engine does not quit when the program is closed, although it is not consistent and behaves differently on different PCs. It is more likely to happen when the program is opened and closed within a few seconds. Waiting longer or sending a request before closing may help it quit properly. It may quit by itself after a few minutes on some systems. Although it's okay on others.
Simply Modbus Master 7.1.2 looks and runs exactly like Simply Modbus Master6.4.1 but was created using a newer compiler. It is a significantly larger download and has an install program. It appears to be more stable with the newer Windows versions. see.....manual7
The size of the registers in the block to be read.
This value should be set to 16 bit registers to read standard modbus registers.
and set to 1 bit coils to read standard modbus coils.
32 bit registers should be used for Enron modbus only.more info...
DTE masters (PC serial ports) have DB9 male connectors which transmits on pin3, receives pin2 and grounds on pin5.A DCE slave will have a DB9 Female connector which will allow the use of a straight through cable. A DTE slave will have a DB9 Male connector and will require the use of a null modem cable.
Modems and radios are used to transmit longer distances. These are typically DCE devices so straight through cables can be used. Some MDS non-spread spectrum radios require RTS Delay to be used so a 4th conductor is needed on pin 4.
RS485 converters can be used to extend the distance up to 4000 feet at 100kbaud. This can be a 4 wire or 2 wire system, depending on the converter. This also allows multi-dropping up to 32 devices on one pair of wires.
The bytes are re-processed immediately as the settings are changed and the results are shown in the fourth column.
Sending another request for a new response is not required for a recalculation.
The seconds taken for the slave to respond to last message.
The number of message responses received (meeting the expected response bytes).
The number of message with an incomplete or absent response
The longest amount of seconds taken for a response (not including failed responses).
The average amount of seconds taken for a response (not including failed responses).
The shortest amount of seconds taken for a response (not including failed responses).
Sets all statistical values back to zero.
When this box is selected, and the SEND button is pressed (or SEND CONTINUOUSLY is selected),
the program will Restore a previously defined Configuration File
and then SEND the request as saved in the file.
SEND CONTINUOUSLY is not saved in the configuration files.
SEND CONTINUOUSLY is always set to unselected when you use the RESTORE CFG button to restore a configuration file.
This keeps polling from automatically starting when you manually restore a configuration file.
If a request*.txt Configuration file is being loaded during a Load before Send,
and the file was saved with LOAD BEFORE SEND selected,
then both SEND CONTINUOUSLY and LOAD BEFORE SEND will both be selected.
Following the LOAD and SEND, the program will wait for the TIME BETWEEN SENDS to expire
before the next LOAD (request2.txt) and SEND.
The program will continue to automatically LOAD, SEND and WAIT through a series of request*.txt files
as long as each file has LOAD BEFORE SEND selected.
When the end of the series is reached and the next file is not found, the series will start over with request1.txt
and continue until SEND CONTINUOUSLY is manually unchecked.
The program will continue to automatically LOAD, SEND and WAIT through a series of request*.txt files
until a file is LOADED without LOAD BEFORE SEND selected.
Following this last SEND, the series will STOP.
The series can be stopped at any time by unchecking SEND CONTINOUSLY.
The size of the registers in the block to be written.
This value should be set to 16 bit registers to write standard modbus registers.
and set to 1 bit coils to write standard modbus coils.
32 bit registers should be used for Enron modbus only.more info...
I am using the program Modscan32 as a master to read and write data of a Siemens module in the profibus network. I can read correctly the information from the module, however when i try to write to the module, the holding register contains the same information than the input registers and it gives me an error if i try to force a bit or word.
Tried again with both programs and the same issue. I try to change some configurations but the error still the same.
Is it possible that we can have a conference so i can show you my screen with the programs? This way you will be able to see it. I took some screenshots of the test. maybe you see what is the error.
Hello @Marcelo what modbus addressing mode are you using? If you are using modbus addressing mode you will read input registers and write to holding registers. If you disable modbus mode and use Anybus addressing mode you can use holding registers for all the data but will need to use a registers offset. take a look at the modbus register mapping in the Network guide.
For the communication, are you getting a exception code in the communication? Or is this a blank communication?
Is Baud rate, pairity, and stop bits?
Are you using two seperate converters? Or are you using a single converter for both?
For RS485, are you termination resistor on the line?
Hi guys,
I'm completely stuck. I've got a Venus GX on my bench that I'm trying to interface to an Eltek SmartPack S battery charger via Modbus TCP. I was told that Modbus is really easy to use, but my experiences are far from it.
So far, I have the Venus GX set to Modbus enabled, and on the Eltek unit I've set it to allow the GX's IP. But I have no idea how to get them talking (they're on the same physical network/subnet).
Everything I read online points to the CCGX Modbus TCP Register List, but that's just a bunch of stuff that I don't understand (yet) - nor can I find out where to enter such values. Surely other people are stuck on the basics? I've never used Modbus before, and have searched these forums and Google extensively, but can't figure out how to even get the Venus GX communicating to another device.
I really like the Venus GX units and we've started deploying them on all sites including solar etc. Using CAN bus on them is super easy, as with VE Direct etc.
Could someone point me in the right direction? I've got the Eltek charger on loan pending if I can get this working - I've got a box of about 10 Venus GX's here and another 100 or so more to order if I can get them doing what I need them to!
Thanks,
Richard.
Your reply is no help whatsoever. I've read the Modbus topics and cannot find answers to getting things to link up.
Also this is hardly a modification; Modbus is part of the GX system.
Maybe I ditch the Victron units and find another manufacturer if nobody can help me. Given the quantity of these we're planning to purchase (we're a telco operator) I would have thought Victron would be of more help.
Hi, Which aspect of the communication are you struggling with? Have you established any data transfer yet? Have you tried a Modbus simulator to read data from the Venus unit? I am more than happy to help you get started. Tell me where you're at and we'll go from there!
The protacol is quite old and has some legacy terminology asosciated with it, coild for example are single bits that can be on or off, think relay coils. Registers represent numbers, originally 8 bit integers, but now typically 16 bit intergers, with the option to treat as signed / unsigned and pick the byte order amongst other things.
In short the device you are asking to give you info is is a slave/server that expects a properly formatted question from a master/client and will respond with an answer that is the contents of one of its registers... Or will accept a value making its register equel to it and then confirm it has done that.
To add to what Alistair says.
For the CCGX, if you want to read a value then you will be want to Read Holding Registers (Function Code 03). The TCP Register List, which you have seen, is vital for deciding what Unit ID and Register to address.
There are various Unit ID's which you need to to know in order to access the bit of equipment that you want to query. The "Unit ID Mapping" tab will guide you on this one. The look up the "Field List" to get the parameter that you want.
I just ran some tests using Virtuino Modbus console for android. cant comment on it but it works as a test console and has pretty switches and displays... Dont know if can run scripts, just wanted a configurable testbed.
I suspect MQTT with some form of HMI/script engine combo, node red perhaps, would be a reasonable way to go but then a PLC with a Modbus HMI has considderable merit too, and would likely be more stable than some cheep box from accros several sea's.
Thanks for the replies everyone; I'll definitely have a look at the Windows Modbus program to see what I can read and write. Also thanks for the Simply Modbus link too.
I'm working away from the office today, but I'll have a look into this in more detail on Monday. I've also got the Eltek rep coming on Tuesday so that we can sit down to try and nut this out!
Will be in touch with my findings after the weekend.
Cheers!
Richard.
The GX is a server, slave in Modbus terms, which means it serves data, or accepts it, as values in a register, that the list of values you are talking about, its a bit like a house number and postcode.
7fc3f7cf58