TPGx00: Fix device niggles

[boeuf-codes]

Where?

As of #7458, the TPG 500 and 300 have some slightly odd issues that ought to be fixed. Below is a description of these issues, lifted from the TPGx00 wiki page:

TPG500

• Error state
  • The ERR command was added to the TPG300 IOC as of #7458. Upon start-up, the TPG500 enters the default No error (0000) state. However, after the first command is sent to the device, regardless of validity, the device is pushed into a Syntax error (0001) state, and this persists for the rest of this power cycle. Thus, the ERR command is currently only implemented for the 300, as it doesn't report anything of use.
• SPS command
  • The SPS command currently is not accepted by the TPG500 (inconsistently with the manual): SPS will receive NAK><CR><LF>, i.e. negative acknowledgement, which is the same response for syntactically incorrect commands. Oddly, when sent as the very first command after start-up, this command will be accepted as per the manual, but for every attempt after, it will be rejected. Thus, this command is also only implemented for the 300 - for the 500 we can infer this information from the 'Circuit Assignment' readback box in the OPI, so it is not necessarily essential.
• Firmware
  • TPG500s will most likely have software version 010100. Upgrading the firmware to 010300, to be inline with minimum version specified by the manual, creates some weird handshake behaviour. Whilst in a persisting Syntax error state as detailed above, the TPG (inconsistently with the manual) will append NAK><CR><LF> (15 0D 0A in hex) to every healthy command. These, however, don't seem to upset the protocol file, so are relatively harmless.

TPG300

• The SPx command claims that the 'switching function assignment' has a repeated B1 measuring circuit: we're not sure if this is a typo or not.

Reproducible?

[Yes]

To Reproduce

• Connect to a TPG500 via ethernet or RS232+moxa.
• Switch on
  1. Send an ERR command.
  2. Send an hex 05 to send <ENQ> after the <ACK>
  3. Error status should be 0000
  4. Repeat 1 & 2
  5. Error status should now be 0001
  6. (If on firmware 010300, (v.) should have a <NAK><CR><LF> appended also)
• Switch off, then switch on again
  1. Send an SPS command
  2. Send an hex 05 to send <ENQ> after the <ACK>.
  3. Should receive the 6 statuses
  4. Repeat 1
  5. Should now receive a <NAK><CR><LF>

Acceptance criteria

• Pfeiffer is contacted about the above issues
• Issues above are acted upon accordingly
• Documentation is updated with the agreed solution
• IOC Tests are updated to cover these changes (temporary tests to cover these issues should be marked by comments).

Notes

Sunil Patel has a contact at Pfeiffer, so this is probably the best route to contact them through.

[zsoltkebel]

I just tested the Error state and SPS commands on the device and they seem to work fine. I followed the instructions for reproducing and they do not result in an error state.

When sending the initial command end with cr-lf but when sending the <ENQ> hex code 05 I did not send cr-lf.
S: SPS<CR><LF>
R: <ACK><CR><LF>
S: <ENQ>
R: <Values><CR><LF>

I was able to reproduce the errors by appending <CR><LF> to the <ENQ> message.
S: SPS<CR><LF>
R: <ACK><CR><LF>
S: <ENQ><CR><LF>
R: <Values><CR><LF>

According to the manual the correct communication protocol is the first version where is not appended after .

[esmith1729]

For ERR bug:

It appears that just using the wrong terminator caused this initial error, which is now fixed in the IOC in the comm protocol.

below is a test of sending the correct terminator after HEX 05 of "none", vs at the end sending "CR-LF", which was causing the 0001 error code.

[esmith1729]

For SPS bug:

Again this was an incorrect terminator being sent of "CR-LF" after HEX 05, which should have a return type of "None":

Below is a test of sending "SPS ", and then "HEX ", and the error did not occur: