Charmed Quark Systems, Ltd. - Support Forums and Community - ClickPLC driver now failing after upgrade

I upgraded to the last posted beta the other day and while the install went OK.

A day or two later the ClickPLC driver went off line and the logs indicate that the PLC address is wrong, sometimes its the wrong function in the reply.

Code:
09/21 20:42:24-Zeus01, CQCServer, CQCDrv_HousePLCThread13

{

    CQCGenDrvS, MEng.User.CQC.Drivers.Koyo.ClickPLC.DriverImpl.196, Status/App Status

    <SendMessage>: sent 8 bytes [01030000000EC40E]

}

09/21 20:42:24-Zeus01, CQCServer, CQCDrv_HousePLCThread13

{

    CQCGenDrvS, MEng.User.CQC.Drivers.Koyo.ClickPLC.DriverImpl.196, Status/App Status

    <GetIncomingData>: got 33 bytes [0001A98F01031C000A00140000001E000500000000000F004400140000159E0014]

}

09/21 20:42:24-Zeus01, CQCServer, CQCDrv_HousePLCThread13

{

    CQCGenDrvS, MEng.User.CQC.Drivers.Koyo.ClickPLC.DriverImpl.494, Status/App Status

    <GetIncomingData>: Wrong PLC Address received 0

I have not analyzed the data string yet to confirm the correct message is going out, but the PLC is responding so its going to be a valid message.

If I pause the driver and then restart it everything is good - the driver goes back on line and the driver is processing the data correctly.

Any ideas as to why this could be happening?

Which of those characters make up the address?

From memory the first two

The message is going to the correct address but the returning message is from address 0.

Not saying its CQC, but my initial suspicion is CQC is pulling the wrong data from the replies coming back.

As quick test this morning, I powered down the PLC and the driver picked up and ran fine. So the issue could be with the PLC - something I find harder to believe but not impossible. More testing tonight.

Charmed Quark Systems, Ltd. - Support Forums and Community

znelbok

Dean Roddey

znelbok