Now that all the above setup is complete, I need to map tens of thousands of words from source tags to Modbus tags.
Is there an efficient or recommended method for handling this large-scale mapping?
I recommend using the Integration Toolkit's RePublish tag action to attach the target OPC Item Path directly to the source tag. (In this approach, you don't need Ignition tags for the Modbus registers.)
As for making the assignments, consider including these tag properties in your UDTs, if any, and scripting the writes to these tag properties for atomic tags.
"Thank you, pturmel, for your prompt response. I'd like to confirm if the above configuration is correct, and if there are any additional settings I should consider."
I have tested the hardware using Modbus Poll as a slave, and I am receiving data correctly. I would like to receive data using the following settings, but it is still not working. The manual only provides the settings shown below, so I am unsure how to proceed. Can you explain the setup process from the beginning with images?
Settings:
Baudrate: 19200
Data bits: 8
Stop bits: 1
Parity: None
COM Port: 11
This test must be completed before proceeding to the next step.
"I've reset all the settings and started over from the beginning, but the same issue still occurs. Do I also need to enable Modbus Gateway Support in addition to these settings?"
Serial communications require matching parity on both ends. Your device must be using Odd parity. Which is strange, as that is optional in the Modbus standard (devices must support even parity). When using no parity, the link must use two stop bits instead of one. (See the serial line Modbus standard at modbus.org.)
This is almost always caused by physical interference (particularly if running RS232 wires more than a few feet). The protocol performs CRC16 checks on each message and discards corrupted messages. This can usually be improved by reducing the baud rate.
I've noticed this, and it's interesting because I'm willing to bet most people are using 8N1 instead of 8N2, if for no other reason than I think that's the default for our driver (and for most serial stuff I've seen?). I wonder why it still works...
Because it only distorts the timing criteria a little, in a generally good direction. But if you are only timing across an entire message, instead of per character, you could allow a gap that should have been rejected.
I default to 8E1, because that is the default in the standard.
The values are written correctly, but I’m seeing the following warning message.
What should I configure to clear or eliminate this message?
org.python.core.PyException: TypeError: 'com.inductiveautomation.ignition.common.script.ProjectScriptModule' object is not callable
at org.python.core.Py.TypeError(Py.java:234)
at org.python.core.PyObject.__call__(PyObject.java:396)
at org.python.core.PyObject.__call__(PyObject.java:461)
at com.automation_pros.simaids.gateway.actors.BulkScriptBatcher.deliver(BulkScriptBatcher.java:51)
at com.automation_pros.simaids.gateway.actors.AbstractBatcher$Processor$2.run(AbstractBatcher.java:110)
at com.inductiveautomation.ignition.common.execution.impl.BasicExecutionEngine$ThrowableCatchingRunnable.run(BasicExecutionEngine.java:550)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
Do I need to include the following code in the valueChanged script for each tag? RePublish.enqSlavePublish(tag, tagPath, previousValue, currentValue, initialChange, missedEvents)
Do I need to include the following code in the gateway event timer script? RePublish.drainSlavePublish()
If it is required, how can I determine an appropriate timer delay value?
pturmel!
The previous issue has been resolved.
Is there a method to exclude a certain group of tags from being written to the Modbus slave while the system is operating normally?
Only tags that have the Tag Actions configured on them will be forwarded to the modbus slave device(s). If necessary, write to RepublishEnabled as needed at runtime.
