Schneider Modbus Software
Alix Stocking
Thanks. I ended up making a test to see for my self. The standard output is only updated every 1 sec (for ION7650), but then I took the Power Module HS and mapped it to a Modbus Slave register and then I could get updates in the Modbus registers every 10ms. For the PM8000 the HS measurements are already mapped to Modbus registers.
The best place to look for this is the ION Template reference. I am not 100% sure but I believe the modbus slave modules are low speed so they update once a second at most. this many not grantee a communication update rate of that speed
Normally the out put register update every 1 sec. but the poll rate of the software like DCS, HMI/SCADA software is set for polling by the user usually more than 1 sec. for example 5 15 depends on how many Modbus device in the network and parameters to be polled of course more device or more parameters the polling interval must be increased.
I have a customer running DCE 7.8.0 that has frequent modbus lost comm alarms using the 3rd party vendors modbus tcp gateway.. The customer had larger polling intervals/time outs and retries, but I lowered them to 10 mins, 15 sec timeout, 3 retries.
Looking at the messages log, its flooded with messages modbus connection failed/timed out so I assume that's just the end device failing to respond or some other physical layer related issue, not a problem with DCE.
Hi, We are trying to link a Schneider TM251MESE plc to ignition with modbus tcp communication. We are able to create a connection between the plc and ignition, but we are unable to link the ignition tags to plc, since we cannot seem to replicate the PLC mapping with modbus addresses. We are reading zeroes for everything but the first few coils (around MODBUS address 000001). Is there anything in the Ignition gateway settings or in Ignition designer that can help us read integer values that are not zero? (i.e. from %QW03 or %IW08).
You missed my point. You cannot do this with Modbus. You will need code in the PLC to copy bit memory to word memory. Modbus word accesses cannot read bit memory. At all.
You can try a third party software like the Kepware-EX, this might get the job done, they have a 2-hour demo package. You could also try read the tags via Python. Were you able to read the tags with Modbus reader?
We've tried using KEPServerEX as our 3rd party OPC server, but we're running into the exact same problem, where we can read %QXx.x things but not holding registers or input registers. We're not sure if we are addressing them correctly (is it 040001 or 400001 for %QW1, is it 400006 or 400011 for %QW11, etc.), since we only read zeroes, but this is a minor issue.
If this is true, then it's the real problem we are facing - we want to read 'bit memory' as 'word memory', but the PLC doesn't do this automatically. It's misleading since the documentation seems to imply we can just read bit memory as words...
Or consider using bit memory (%Q) for bits and word memory (%M) for words, as Modbus' original architecture is designed to do. That will avoid the race conditions that manual implementation of Read-Modify-Write cycles suffer.
The same sort of issue happens in KEPServerEX and from Ignition Gateway where we cannot write booleans. Would anyone happen to know why? We are certain the address is correct (we can set booleans by just defining them as words and then writing the appropriate decimal number corresponding to the bit).
To my knowledge, you must specify the address in variable tables in PLC, if you want that variable to be visible on Modbus, since that address in variable table is also a Modbus address. I used word memory, which corresponds to holding registers.
The problem you have now is the same as mine, the fix is a few posts above.
I know this is a very specific question, but I'm hoping someone can help resolve this issue. We are hoping to start pulling in information from our PM8000 to our SCADA system using wonderware. I am using the default modbus registers. I have good quality in the connection to the device but only certain tags are pulling the correct information. For instance, Current A is pulling as an integer, Current B as a Float, and Current C and Current Average are showing 0. I am attaching the setup from System Management Console. Has anyone else encountered this issue? Volts mode is setup as 4W-WYE
Are you sure the master is polling Current C and Avg current? Lots of masters intializes holding registers (the tag for data it receives) to a value of zero. If not polled, the master register shows its initialized value of zero.
If you are using one based register numbers and mixing that with zero based numbering, you might be reading and interpreting the wrong set of registers. 32 bit floating point values require two adjactent registers, for instance Current B uses 43002 and 43003.
When attempting to read 43002 and 43003, you might be off by one and getting 43001 and 43002. The word/byte order changes when that happens, but I've seen where the resulting mixed-registeer value appear to be close to what it should be, yet be incorrect.
If it were me, I'd try disabling the zero based addressing function and then do whatever is necessary to try alternative word/byte orders until something reasonable appears and whether you get full FP values.
To expand on what PV_DAQ has said, have you tried to read the registers from the device with a modbus client other than the system you are using? tester.exe for example or modbus poll, ModScan etc. The idea would be to poll registers to get the explicit 16 bit values (some modbus clients can convert these into 32 bit floating point values for you). The point is to very that device is responding to modbus polls as expected. There are also online tools that can help you convert hex numbers into floating point numbers -schmidt.net/FloatConverter/IEEE754.html
regards,
PLC noob here. So go easy on me if I am wrong. I have seen that at some of the projects, we read the status of digital outputs of PLC to SCADA(Citect) using a Modbus Read/Write Register and performing a BITAND operation. This is perfectly fine, I assume, as you get to save a lot many tags. Now this is not where the problem lies, the issue is with the tags in PLC that constitutes the bits of the previous mentioned register. Let me try to explain, Say, I have a 16channel DO, and at PLC side (let's say Schneider M580) we have 16 tags that becomes ON or OFF as a result of logic execution and at the same time constitutes the 16bits of an integer stored in 40001. This integer is supposed to report the status of DOs in SCADA with BITAND function and also write data to the device tags with a move function which would turn ON or OFF a field device. Now if there was a device that could write data to modbus registers (40001 in our case) faster than PLC's scan cycle, wouldn't that device be capable of altering the DOs?
(I have not tested this. Neither have I done any PLC programming on my own without supervision. I am familiar with embedded devices and LabVIEW. I have seen such a code and before executing my first own project in PLC I just wanted to know if this might be possible and at the same time do tell me if this is the right way to program. As of now, what I have planned to do is write status of device tags to a register and read that register rather than going the other way around.)
This is a known security risk to existing PLC applications, especially when the PLC is left completely "open". Modern PLC systems and software have the ability to prevent certain actions, but again if the PLC application is configured with all security disabled or on older systems this is a security risk. Documentation is available that show how users can prevent this from happening can be found here:
Writing data faster than the PLC cycle time is not possible: In a Modicon PLC/PAC the access for the communication interface to data memory inside the CPU is only accessible between 2 scans. So writing faster than cycle time is not possible.
When you write data to a Holding register (ex. 400001 or %MW1) you will overwrite the existing data. When this data is used to activate Outputs, you might set/reset outputs. This also depends on the PLC application itself. If the data of this Holding register is used as setpoint for by example a PID controller controlling temperature, you are basically entering a new setpoint.
In this example the T300 is requesting a read of the 2 registers that indicate the state of the local plant digital inputs of the meter. The reply message from the meter has the top bit of the function code set (0x83) to indicate an error and the next byte specifies an exception code of 2.
Likely this level of troubleshooting would be better done through a technical support case. There are modules inside the ION meter template that map ION register to modbus addresses. Most of this is done through Data mapping modules. Different modules map different groups of registers. Likely tech support would want to see the states of the ION registers at the time of modbus not communicating.
I can use an example. Inside the meter there are multiple Power factor registers, Power Factor signed, Power factor leading and power factor lagging. A system cannot be both lead and lagging, so when system is leading, the register for PF Leading is a value, and PF lagging is "N/A". If system is lagging, PF leading is "N/A" and PF lagging is a value.
ff7609af8f