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?
You can view the program in zip file, (From program_Img1 to Program_Img7 , is just one OB30 everything else is diabled so only OB30 is running.). Slave ID and Data addres are correct as u can see at Simple Modbus Master Images where I directly connect from PC to microCPU device.
I dig even deeper into modbus_master DB and I checked SendBuffer, Its shown on SendBuffer img and when u compare it to Simple Modbus Master Read 2 u can see that CRC bits are on starting position in PLC and in PC program in Last position can it cause that 8281 error?
for first tests better prepare only one request to Slave, then you can better check all statuses. Also for better check you can make pictures in Online mode, better then see what value is set to MB_MODE, what address is set for register. From my point of view:
1. make sure (look to instance DB of comm cfg) that 2 wire RS-485 is really set, what I remember some kind of bug was reported and therefore not correct value of interface was set in DB via module cfg.
4. in case of check correct message format outgoing from PLC you can connect also Modbus Slave PC application or other simple serial Terminal program (not strictly Modbus version). After sending request from PLC you can see in your PC Slave app what message was sent and you can easy check byte per byte if some problem exists. Looking to send instance DB isn't good solution now in my opinion.
Update: hope you've check for sure output DONE -> true in COMM_LOAD, without this is next step with communication not sure... Also check correct Module HW address set in COMM_LOAD, this error can point also to this problem. In this case your Master block can't working correctly. All sequences must be executed correctly one after other.
I corrected EN inputs and the DB pointer to word changed to symbolic adresing to word. Installed Simply Modbus Slave and connected PLC to PC via CM PTP MODBUS RS485. The instruction MOdbus_Comm_Load is executed without any problem the done bit is save to Comm.Hold_Done bit and status in that state is 16#0000. The Comm port parameter are correctly set as in HW config as shown on IMG Modbus_Comm_Load_DB_Port_Records. Only MOD and RETRIES are set at start of OB. Next is Modbus_Master which is not executed till Comm.Hold_Done is not set. There is tag read. When Read is set the status of Modbus_Master go to 16#7001 or 16#7002 and Busy is set. After second latched on of Read tag the status go instantly to 16#8281 (Negatic aknowladge) and Error bit is set. I checked MB_DB and its set correctly. I tried 40001 and 400001 data adrresies and swaping D- and D+ and chenging version of modbusRTU from 3.1 to 2.1 but nothings helps :(
So I think that real problem is in Modbus Master Send P2P because lot of parameter are missing, I tried set Send_buffer before instruction but its set back to som bulls... inside the instruction.
maybe really better can be now omit cyclical OB and put your code to some FC/FB with OB1 execution. Nothing special for this test. Via your picture with MB Slave PC app I don't see any request outgoing from PLC. Maybe via standard OB1 execution it can be test better now. Also set that REQ as simple memory one condition. You can also make next simple condition that if Master DONE or ERR is true you can reset your Master REQ request. Really I recommend for first tests make code very simple with 2 instructions only - Comm_load and Master. Without any special conditions you can easy test functionality.
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.
If you are using a serial interface it is likely to be RS485, although there is technically no reason some that other physical standards cant work, and in this case the subtype will be RTU, as opposed to ASCII.
If you are using Modbus TCP it is generally even easier as the ethernet standard and TCP stack will handle everything in the background, other than addressing, which in this case would be the IP address of the GX and a device ID, which may be called a drop number in some clients, that the GX will use to send your query to the corerect device.
e59dfda104