i am using the AC Control Box on a xArm5. The Function read_holding_registers(256,1) seems not to work properly as intended…
We are using many Blockly programs, which are called via Modbus TCP. It depends on the current state, sometimes we call multiple blockly programs in a row via the Registers 0x30… This is working as intended.
Sometimes a blockly generates a custom “fault”, which is stored in TCP Register 256 [ self._arm.write_single_holding_register(256,val) ]. This value is then read by the SPS to display other things, react ect.
The value with this “fault” is always greater then 0, thats why we want to read this value in every blockly program at first, so we can skip these without any commands. But this gives me always the error code inside the tuple of 3 => timeout happened. [ val = self._arm.read_holding_registers(256,1) ]
Is there any issue with this? Am i doing something wrong here?
Would you please provide a simple Blockly project for us to reproduce the problem?
When did you call read_holding_registers and write_single_holding_register?
we want to use the read_holding_registers at the very start of each blockly program to check if register 256 is not null. Then we want to return of these programs. the write_single_register do happen at every application fault, when something is not going as intended (not “hard errors” like crash, touching ect, out-of-bounds ect.)
I upload a Picture, as i cannot upload the download from the config website.
I tried the code below, but everything works fine. Please update the firmware and UFactory Studio to the latest V2.3.0 version, and see if still an error.
Register 256 is reserved and undefined, but please note that it will be reset to 0 after rebooting. What do you mean of 'a blockly generates a custom “fault”? We don’t have such logic, did you store ‘fault’ in register 256 yourself?
thank you for your help. i just updated the Software & Firmware from 2.1.0 to 2.3.0.
We use the Registers 256 & 257 for our Applikation results. I try to explain this:
We use a combination of blockly tasks, launched from Modbus TCP.
We are using the Cobot for a Pick&Place Application. With the Vakuum Gripper.
It “could” happen, that the Vakuum Gripper is not able to pick something up.
This is checked inside a blockly tasks. On these Events, when something is wrong within our specific usage, we want to let the SPS know, what happened and where. Since the Robot didnt collide or put some other defined error, we were in need to use a different output channel.
This is, what we use the Addresses 256 & 257 for.
