CCD100: Confirm we can communicate with new model [TIMEBOX: 1 day]

[DominicOram]

As a scientist on various beamlines I would like to be able to communicate with the new CCD100 devices bought by pressure & furnace. JN has done the wiring on these but CG has bought them.

Acceptance Criteria

• Second CCD100 is tested
• Any oddities about the device are documented on the wiki (we know they use USB over serial so we may want to document cabling at least)

[DominicOram]

See email chain on experiment controls inbox for more details

[FreddieAkeroyd]

Is this the same device as in #3821 ?

[rerpha]

Will be having a play with one we've got in the office to see how we can talk to it.

[rerpha]

Have sent off an email to manufacturer to find out if we need to use a specific usb-C to rs-232 adapter as yesterday it wasn't giving the correct response back from the commands sent and instead echo'd weird characters. the baud rate etc. is all fixed going by the manual and this was all set correctly.

[rerpha]

No luck with our IOC via ethernet - sending weird null chars after the line feeds, and sometimes random data.

Will put this in impeded for now as I would like to know if we are using the right usb-c to rs-232 adapter cable.

[rerpha]

Ok, this is no longer impeded as the manufacturer has stated you can't use usb-c to rs-232. We will be able to talk to the CCD100 via ethernet, however our IOC will need modifying to suit as there were some funny looking line endings that weren't being parsed by the IOC properly. The commands we were sending from the IOC seemed correct and gave an output but weren;t in the correct format.

[rerpha]

Still as part of this ticket we need to:

• make our IOC work with the new CCD
• confirm with CG that we can control and configure it at the same time

[rerpha]

I';m not finished yet but thought i should post an update. we expect the device to return as follows on a query

*<a>*:<cmd>;<params>\CR\LF
<data>\CR\LF
!<a>!<response>\CR\LF

but there are two things wrong. Firstly instead of the above it will respond (if behaving) with this:

*<a>*:<cmd>;<params>\CR\LF
<data>\CR\LF
!<a>!<response>\CR\LF\000

as the packet seems to have a null terminator byte on the end of it. have got around this by using either \00 as the interminator or the entire command-ok sequence which seem to work fine.

The second issue is that the device sometimes ONLY sends the last part of the response like so:

!<a>!<response>\CR\LF\000

which currently causes the PV to go into read alarm even with a mismatch handler. Freddie and I looked with Wireshark and the device truly was not sending the first part of the command with the command and then the data so this seems like an issue in the device. nowhere in the manual mentions it either!

progress so far:

ISISComputingGroup/EPICS-ioc#624
ISISComputingGroup/EPICS-CCD100#6

[rerpha]

Next course of action is I am going to email the supplier. This doesn't seem like the correct behaviour. We can live with the \00 terminator but the spurious messages are making things difficult.

[rerpha]

email sent off, putting in impeded

[rerpha]

Tested, but needs an asyn interpose layer writing to remove NULLs and so cleanup code

Might ask for a hand with this in the new year if possible please

[FreddieAkeroyd]

Putting impeded as need to retest in lab with new asyn interpose and will not be able to do that before sprint end; also need to see if we can use mk3 modified protocol file with original ccd or need to keep them different

[FreddieAkeroyd]

So all looks ok with device, the times that it send no response will cause the PV to briefly CALC alarm though. need to test with mk2

[FreddieAkeroyd]

Have merged new protocol under new name devCCD100_mk3.proto in ISISComputingGroup/EPICS-CCD100#8 so it is on instrument if needed, putting into impeded until can check with original and merge protocols

[FreddieAkeroyd]

The devices have been returned and the protocol file was merged to allow use in 10.0.0 so it is only a "code review"