Can a Button Tag get stuck in an "ON" state?

[PeteLam]

I have a machine in a remote location that is behaving strangely. Basically, the machine cycle is starting before the operator pushes the "start cycle" tag.

I have the tag disabled until certain parameters are satisfied, but the cycle seems to start at the very instant the parameters come within tolerances.

It's definitely possible that this is a programming bug, but the machine passed Installation Qualification about 4 weeks ago, and has been used at least part-time ever since. This problem was never seen here at the factory during the development phase.

Is it possible that there is a hardware problem with the touchscreen that would cause this particular tag to always trigger as soon as it is enabled?

It is very difficult to troubleshoot because this machine is, for the time being, a one-off prototype. I don't have a test bench here in US that I can use to duplicate the problem. If I can't fix the problem remotely, I will have to fly to the site and troubleshoot in person.

[stuartm]

No. It cannot. Unless its scripted on initialization.

A good way to test it, would be to use the DEMO driver. If it sticks using the Demo Driver then yes, you do have a touch screen issue and should get an RMA.

[PeteLam]

Just an update for anyone interested:

Found the problem. The Modbus register bit in the Yaskawa machine controller had somehow been set to TRUE and got stuck in that condition. Interestingly, the condition persisted even after re-downloading the program in the Yaskawa and the Beijer T10A. I'm not sure if this is normal for Modbus or if it is unique to the way Yaskawa implements the protocol.

The solution was to embed some actions in the T10A to force the bit to FALSE upon startup. In retrospect, this would be good practice, but I've never had to do this before since variables usually default to FALSE upon bootup unless intentionally configured to be retentive. In this case, the bit was not supposed to be retained, but it was anyway. I'll have to explore this more with Yaskawa.

Also, not sure why it got stuck in the first place. The bit was controlled using a button which had a Mouse Down=SET Tag and Mouse Up=RESET Tag. In theory, the Mouse Up=RESET Tag should always occur, but I suppose there might be some rare occurrences where it wouldn't.

[Patrick Hall]

I realize this is a bit of an older thread, but I would like to offer up a possible explanation to your observations. Of course this is only relevant if the following assumption on my part is an accurate reflection of your actual Yaskawa target.

Your description of events is reminiscent of the behaviors I know to exist on Yaskawa IEC based platforms. MP2300Siec, MP2310iec, MP3200iec and MP2600iec. If your target is in fact one of these units then the following applies as a general rule regarding Modbus on these systems.

By default, MWCT (The hardware configuration tool) in the MotionWorks IEC programming environment disables Modbus Slave functionality. When it is enabled, the "Retain Modbus Inputs" also remains checked. See Img.

MotionWorks Hardware Configuration Tool, Modbus Server/Slave Specific configuration.

mwct_modbus_cnfg.jpg (26.27 KiB) Viewed 16588 times

The way the MPiec platform operates, is when this retain input setting is enabled, a portion of the controllers battery backed SRAM is used to retain the input bits (FC#05 "Coils") and Input Registers (FC#06,16). Once a bit or value is set that state is preserved across power cycles, project restores (even completely new projects). The way to clear this retained data is either via the webserver on the controller (Initialize SRAM) or boot the controller with CNFG and INIT both ON (to the left), or alternately disable retain input, download program, reboot controller. The down side is that on many Modbus Masters, they read then write, or read/write/read these areas, and unless the data is persisted on the HMI you will see that your data entry reverts to False, or 0 values.

Additionally, Clearing SRAM in this way also clears ABS Encoder Offsets (which are retained on the MP after the first MC_SetPosition is executed). Be cautious in this regard if you are using a Servo motor with the ABS Encoder and Pn002.2==0 (Use ABS Encoder as ABS Encoder) versus Pn002.2==1 (Use ABS Encoder as Incremental Encoder) as any previously defined position frames will shift and if the axis is of finite travel you may crash the machine into other mechanical parts... Always re-home if the Offset is cleared.

The way I write my code on the MP is such that modbus command bits are latched so that even if the enable, jog or move start bits are true on boot, they do not effect motion until a complete false->true RE is detected again after boot. Since the MotionWorks Platform (KW MULTIPROG) does not support direct writes to %I memory mapped data (as is the case network inputs Modbus or EIP on this system) there is no way to clear the retained input on boot you must either program such that commands are only valid if a transition FALSE->TRUE is observed otherwise mute/lockout that "command", or disable Retained Inputs, and configure the HMI as Write only for input, and ensure that on startup the current values hmi side are forced to the slave. It has been a while since I last did a Beijer HMI project so I do not recall what steps are necessary (or even available) to perform this feat on the HMI.