Question regarding PF6000 and how KepwareOPC sets the JOB_JOBNUM value.

[AS_12348596]

Hello again, I have a question regarding how Kepware, using OpenProtocol handles the Job Info commandset.

I have been told by an AtlasCopco representative, that before sending a Job Number via the message "Select Job" (MID38) to the PF6000 device, I must send a seperate message: MID30 "Job Number upload request". 

0030

Job numbers upload request

Open, FEP

Based on the documentation available to me, I can see that the Job Number Data command set uses MID30, then use MID31 to request information.

However, because the values in the Job Number Data commandset are Read-Only, I do not think I can explicitly send this UploadRequest(MID30) before setting the JOB_JOBNUM value. (MID38) 

As such, I would appreciate the following information.

1. Does setting the JOB_JOBNUM value via KepwareOPC, automatically send a upload request message (MID30), then the Select Job(MID38) message to the device?
   1. If setting the JOB_JOBNUM does not automatically send a upload request message, how can I explicitly send the UploadRequest (MID30) before setting the JOB_JOBNUM value?
2. I have also noticed that the device's property settings has a section for message revisions. On it's own, I cannot really tell what changing this revision does.
   Is there any way for me to see what the difference is between each revision? (From 0~2) I need a way to match this revision with the revision details I recieved from AtlasCopco.
   1. Alternatively, is there a way that I can monitor the MIDs the OPC Server sends, and what order they are sent in, without connecting to an actual device?

Thanks in advance, 

Azu

[MRohilla · Accepted solution]

Greetings,

1) No, setting the JOB_JOBNUM value does not automatically send a MID 30 request.
1a) Adding the JOBN_COUNT or JOBN_ID tags and having an active subscription (either UA or DA or some other interface) to one or both tags will cause a MID 30 request to be sent.
2) The help talks about which message revisions affect which MIDs. The revision values themselves come from the protocol documents, which can be obtained from Atlas Copco. Specific tags will need certain revisions, and those can be found in the help document under the Data Range column.
You will need to get a protocol document from Atlas Copco to see the exact differences.
2a) I don't know of a way to do this without connecting to a device. With a device and Wireshark installed, you can see the communication but will need the protocol document to understand what is being sent back and forth.

Regards,

Mohit

[AS_12348596]

Hello! Thankyou for yiour answer.

I was wondering if you also know anything about how KepwareOPC handles the VIN_VIN value, and the corresponding MID50~MID53 messages for PF6000.

Initially, when looking at the VIN_VIN value via OPC Quick Client, the value will be displayed as "Unknown", with Quality displayed as "Bad (Out Of Service)".

However, I can still write to the VIN_VIN value as displayed in Kepware. Writing a value to VIN_VIN results in the value I wrote being correctly set. (Visible from Atlas Copco's Open Protocol Interface Tester and OPC Quick Client)

This raises the uncomfortable situation where I don't precisely know whether KepwareOPC is actually failing to subscribe via MID 51 (Vehicle ID Number subscribe), due to a configuration problem on the PF6000 side; or if the VIN_VIN value is simply empty. (In this situation, lets assume there are two modes for PF6000. One which is setup for Kepware, and one that is not.)

It is also likely to cause issues with other third party MES Software, which really does not like reading from, or writing to addresses that are "Bad (Out Of Service)" .

Is there anything I can do to remedy this situation? ie, Is there a way to make sure I can identify situations where Kepware is unable to subscribe via MID51, seperately from situations where Vehicle ID Number is simply blank? Alternatively, can I change how Kepware determines a address is "Bad"?

Thank you again!
Azu