Delay or instruction to use to write a different value after reading it.

[Noe]

Hi

I am using an integer value at PLC side as a way to define actions taken by PLC and VB app. Some values trigger actions as VB has an .onvaluechange event, and some trigger actions at the PLC.

Works like this:

A basiclabel reads the value on the integer variable at the PLC side.
Onchangevalue event will compare value and, if applicable, takes some actions.
If actions were taken, VB will write a new value (using a write command) to the same variable for the PLC to know it, and also reset it to an idle state or advance in logic.

Problem is that sometimes the integer value is not being written after the actions are finished at the VB side, like if the PLC would not accept the write command from AHMI.

Questions are:

Does this have to be with subscriptions working on basic labels and not with command write (that's is what I understood so far)? Like the read process is not finished when I try a write from code so the PLC ignores it. This happens only if I do it very quickly manually, changing the integer value at the PLC side a couple of times. In auto, it happens occasionally, like a 5% of the times I tried.

Is there another way to write values to PLC from AHMI that would be a warranty they will be written? I've seen Archie's post asking people about if they used code or just controls as this could be a cause.

Can some one point me to some information about subscriptions?


Any help will be gladly welcome, I am sorry if this has been discussed before, but I already searched the forum and couldn't find any similar information.

[Archie]

This really should work. The two things I would try is to handle the ErrorEvent of the driver to see if it fires. You can just put "Dim dbg=0" in the event handler and point a break point at that line of code.  This will tell you if an error is detected during the write.

Another thing I would do is to create another dummy variable in the PLC and write to that one also. This will make sure the PLC us not overwriting the value and also can tell you if one write fails, but a second succeeds.

[Noe]

Thanks Archie, I was trying out your suggestion when I stumbled with the answer: human factor.

Operator was pushing the reset button several times per second, as a result, it kept writing the variable from the PLC side several times (I used an OSR before the mov) and blocking to the VB to write its own value. Adding a TOF so even if the operator presses obsessively the reset button solved this, so only one time per second the value will be written, giving a chance to VB.

This was driving me nuts, as I could only see it happen when running in full auto, and as we have 3 simultaneous stations from this PLC it was hard to see every move from people.

So I think the value was being written from VB, but the PLC was still writing values as response to operator input, so it got quickly replaced and never seen.

I would believe the PLC sends an acknowledge to a write request, that if its not received, AHMI should send an alert, or at least that's what I understand.