IRIS : Mclennan PM600 ioc needs updating.

[GDH-ISIS]

I believe that the Mclennan IOC does not poll the device at all times - I have just confirmed this on IRIS, and Jon Bones had some issues this morning. It would be very helpful if we could change this so that the position, limit switches and home switch are reported at all times. This helps greatly with diagnostics and feedback to the user. It may have been addressed from the version on IRIS, but if we could confirm it, it would be appreciated.

1. Communication with device - MOXA transmit and receive lights are very useful - these then coincide with transmit and receive lights on the crate.
2. Checking limit switch operation.
3. Checking homing switch operation.
4. If the axis is jogged (using the hardware crate) or moved by hand by the sample environment group, you need to see the dynamic changes.
5. Finally and most importantly, if the device is not polled, how do you know that the communications are good and that the cable is still plugged in!!

[John-Holt-Tessella]

@AdrianPotter knows most about this I will arrange a meeting.

[kjwoodsISIS]

These are, in effect, additional requirements that were not made explicit at the time we created the original McLennan IOC. They might well apply to other devices too. In which case, we need to

1. make a point of asking whether an IOC should regularly poll its device
2. make a point of not assuming that "someone" will design the IOC so that it does poll.

In other words, we should always try to state requirements explicitly.

[ChrisM-S]

There are generally two sorts of devices, those that chatter to the computer regardless of whether you talk to them, for those an IOC should treat this chatter as a heartbeat (i.e. timeout and report a comms. error if it doesn’t receive what it should within a time). We’ve generally not preferred these sort of comms. if we have a choice because they can be a bit awkward to program and are by definition asynchronous with the code talking to them (unfortunately, hardware people often quite like these).

Alternatively, there are devices which only speak when they are spoken to. These must be polled because as @GDH-ISIS points out, this is the only way we will know they still are working. In fact, they must really be polled so as to return at least one value, devices which accept silent commands need to checked for data coming back (one wire may not be connected). The rate of polling for data can then be set lower than this (or on demand) if values are not needed very often.

As far as I can think, this will apply to any device connected to any simple serial "bus" RS232, Ethernet, MODBUS etc. There is a point to be made that between two bits of code on a local system, polling is generally a poor idea (software should use events/interrupts). When talking to real hardware without its own interrupt lines, it is almost essential.

The network load of polling is generally very low for real RS232 speeds (the CPU load of over-polling might be higher though). On the Ethernet, saturation of an Ethernet link is possible, but as long as the device is fairly dumb and one waits for a reply, the chances of a very tight loop are quite low (I would always put in a delay though).
Hope this helps.

[kjwoodsISIS]

I think the above information needs to be incorporated into Creating an IOC in the IBEX Developer's Manual.

[ChrisM-S]

Good idea, Its there now (edited up a bit) if anyone wants to move change edit/delete feel free it's
here - Some Design thoughts for a serial/Ethernet IOC

[John-Holt-Tessella]

Also make sure that waitfor_move("BLOCKNAME") works. Currently gives:

g.waitfor_move("POS")
Unable to find PV TE:NDW1407:CS:SB:POS.LVIO

Could not get limit violation for block POS

This works with galils

[AdrianPotter]

Make sure existing behaviour (e.g. homing via sequencer) and reset on move are preserved

[John-Holt-Tessella]

Consider doing #2897 as art of this

[John-Holt-Tessella]

Put scan on status update field (see @FreddieAkeroyd )