Maps: Analogue fermi chopper: communicate

[Tom-Willemsen]

The analogue fermi on MAPS responds with a subtly different syntax to Merlin's.

Main differences are:

• Nominal frequency comes back as a hexed number rather than an enum/lookup
• Nominal frequency setting also needs to be done using a hexed number rather than enum/lookup
• Chopper clock speed is different on MAPS.
• Autozero calibrations are different

[Tom-Willemsen]

Having some issues setting speed onto the chopper crate. The IOC appears to need to send the command 10 times to get the controller to accept it. I think we have similar issues with the other setpoints (command, phase delay, gate width).

This does not work at all:

setSpeed {
  wait 200;
  out "#3%0.4X%\$1.0<julich>$";
  out "#3%0.4X%\$1.0<julich>$";
  out "#3%0.4X%\$1.0<julich>$";
  out "#3%0.4X%\$1.0<julich>$";
  out "#3%0.4X%\$1.0<julich>$";
}

This works consistently (exactly the same as above, but with 5 additional out commands):

setSpeed {
  wait 200;
  out "#3%0.4X%\$1.0<julich>$";
  out "#3%0.4X%\$1.0<julich>$";
  out "#3%0.4X%\$1.0<julich>$";
  out "#3%0.4X%\$1.0<julich>$";
  out "#3%0.4X%\$1.0<julich>$";
  out "#3%0.4X%\$1.0<julich>$";
  out "#3%0.4X%\$1.0<julich>$";
  out "#3%0.4X%\$1.0<julich>$";
  out "#3%0.4X%\$1.0<julich>$";
  out "#3%0.4X%\$1.0<julich>$";
}

Notably, LabVIEW only sends the command once and it appears to set consistently. @davidkeymer and I have had a detailed look at the LabVIEW and it doesn't look to be doing anything special - just "set and forget".

I've tried a variety of things to get it to work with a single command in the IOC, none of which had any effect:

• Many different combinations of timeouts and waits in different places
• Speeding up/slowing down poll rate
• Retrying after n seconds if the command didn't appear to set properly for various values of n
• Swapping out the epics serial driver for the visa serial driver
• Creating a completely independent python script using pyserial - this exhibits the same behaviour as the IOC

@FreddieAkeroyd any ideas about differences between labview serial comms and other serial comms? Are there any low-level serial settings that could be catching us out? I've double checked all the "standard" settings including software and hardware flow control.

[FreddieAkeroyd]

If you can use "visa serial" from EPICS can you run NI Spy on both labview and EPICS and see what is different? I guess an asyn trace suggests all ten out commands look the same? If the protocol only sends the command once, do you need to write to the PV 10 times to get it to work, or does it never wirk? Have you tried setting "clocal" and "crtscts" set to "D"? Does the moxa web interface confirm COM settings are the same when both are connected? We can discuss more tomorrow - where is the LabVIEW Vi by the way?

[Tom-Willemsen]

Hi @FreddieAkeroyd thanks for the comment, gives me a few ideas for continuation at least

In terms of your questions:

• I forgot I could use NiSpy with the visa driver - thanks, I will try it tomorrow
• Yes, asyn trace shows all ten commands are the same (the python script I wrote also sends a hard-coded command which is the same 10 times)
• If the protocol only sends the commands once, if I process the PV 10 times in very quick succession it works but seems to be somewhat flaky (possibly due to one of the scanning records going off in the middle and sending a different command??).
• I didn't check the COM settings via the moxa but I did double and triple check they were correct in the st.cmd compared against labview. I will also check against the moxa webpage tomorrow, thanks.
• Yes I've tried with flow control set to both the usual Y/N combination and D/D: no effect either way
• The labview VI is in labview modules/instruments/MAPS/MAPS fermi chopper

[FreddieAkeroyd]

Hi, just looked at Vi and it seems to set the serial port read and write buffer sizes, these are something like 4096 characters by default but the Fermi sets these to 128 bytes for read and only 16 bytes for write. Given each command is 9 characters, the serial port write buffer will not hold two commands. Maybe there is some funny writing/flushing interaction that setting low buffer sizes gets around? Currently it is not possible to set the buffer sizes in asyn, but it could be added. You could configure the port to do a small serial break after a write, that does a flush before it does the break, maybe the "flush" will help the command when the buffer size is larger than in labview.

[FreddieAkeroyd]

recompile asyn with the following to temporarily set the buffers to what labview does

in the connectIt() function in drvAsynSerial/drvAsynSerialWin32.c after the call to CreateFile() add:

if ( SetupComm(tty->commHandle, 128, 16) == 0 )
{
    printf("error setting com buffer sizes\n");
}

Other things to try are, at end of writeIt() function in the same file add:

FlushFileBuffers(tty->commHandle);

maybe using a serial break will help too?

[Tom-Willemsen]

• I tried the two suggested changes to asyn - no effect
• I tried sending various serial breaks after the command - If the break length is zero, no effect, if the break length is greater than zero, the device never replies to any command
• I didn't get as far as looking at logging from NiSpy before Paul Chorley wanted to use the chopper again.

Paul will let us know when we can next use the chopper.

[FreddieAkeroyd]

Can you use NiSpy with the emulator?

[FreddieAkeroyd]

It may show all visa calls, though the IOC will probably work it may help trace subtle differences

[Tom-Willemsen]

@davidkeymer dug out an emulator that FZJ provided a long time ago, so I have tried to get that talking just in case that helped diagnose a bit more while we don't have hardware access.

• It's a DOS program so I'm running it in a FreeDOS VM in virtualbox
• I'm tunneled the COM port through from the VM to a real port on my computer, at which point I can use the MOXA physical loopback to connect the labview driver
• Their emulator did not boot up at first because of a divide-by-zero error. From the syntax of the error message and the attached sources it looks like Turbo Pascal was used - Turbo Pascal had a bug in one of it's libraries which means compiled programs can't be run on CPUs faster than 200MHz
  • I've tried limiting CPU utilization in virtualbox but this doesn't look to have helped
  • I downloaded a patch for the above problem from http://www.ipnet6.org/tppatch.html
  • The patch claimed that it didn't apply successfully (in German), however I have now been able to run mapssim002.exe up which gives the interface below:

[kjwoodsISIS]

@Tom-Willemsen & @davidkeymer - good sleuthing to find this & try it out.
I am trying to understand where responsibility lies for sorting the problems we are having with the FZJ chopper. Are we being made to jump through hoops because there is a problem on the FZJ side? Or have we been provided with inadequate documentation?