Ticket3071: Add IOC for Kicker PSU #313
Conversation
…mputingGroup/EPICS-ioc into Ticket3071_Add_IOC_KICKER
ghost
mentioned this pull request
| @@ -0,0 +1,6 @@ | |||
| ## NI cDAQ-9185 | |||
| epicsEnvSet("CDAQAI","cDAQ9185-1D195CFMod3") | |||
There was a problem hiding this comment.
Is this a hard-coded address for this specific hardware unit, or is this a more general model number which would allow this IOC to be used by other instruments or facilities? If it is tied to a single unit, could this be made more generic through macros?
| epicsEnvSet("CDAQAI","cDAQ9185-1D195CFMod3") | ||
|
|
||
| ## input | ||
| $(IFNOTRECSIM) DAQmxConfig("R0", "$(CDAQAI)/ai0", 0, "AI","N=1000 F=1000") ## Kicker Volt |
There was a problem hiding this comment.
The N and F values will be important when analysing data from the DAQ, and I think are probably of use to the instrument scientists as well. Would it be possible to set these as macros? It may even be worth writing these values to a PV.
| < $(IOCSTARTUP)/dbload.cmd | ||
|
|
||
| # Load up DB records for talking to the DAQ box | ||
| < iocBoot/iocKICKER-IOC-01/st-daq.cmd |
There was a problem hiding this comment.
👍 I like that the two devices are separated out into different files
| < iocBoot/iocKICKER-IOC-01/st-schneider.cmd | ||
|
|
||
| ## Load our record instances | ||
| dbLoadRecords("$(KICKER)/db/kicker.db","PVPREFIX=$(MYPVPREFIX), ,P=$(MYPVPREFIX)$(IOCNAME):,DAQMX=$(MYPVPREFIX)$(IOCNAME):DAQ:, PSU_MAX_CURR=$(PSU_MAX_CURR=15),RECSIM=$(RECSIM=0),DISABLE=$(DISABLE=0),PORT=$(DEVICE)") |
There was a problem hiding this comment.
PV names in IBEX tend to start with
| $(IFRECSIM) drvAsynSerialPortConfigure("$(DEVICE):PLC", "$(PORT=NUL)", 0, 1, 0, 0) | ||
|
|
||
| ## For real devices | ||
| $(IFNOTRECSIM) drvAsynSerialPortConfigure("$(DEVICE):PLC","$(PORT=NO_PORT_MACRO)",0,0,0) # change this |
There was a problem hiding this comment.
I had a poke around the schneider M580 documentation here, which suggests that it communicates Modbus over ethernet. It's not a big change if it is, just something to look out for when you hook everything up
| < $(IOCSTARTUP)/init.cmd | ||
|
|
||
| ## Modbus configuration | ||
| drvModbusAsynConfigure("$(DEVICE)heartbeat", "$(DEVICE)", 1, 3, 649, 1, 0, 1000, "PLC") |
There was a problem hiding this comment.
Can this modbus port definition be moved to the st-schneider.cmd file with the other one? Perhaps with a comment explaining what they both intend to access
|
|
||
| ## Load our record instances | ||
| dbLoadRecords("$(KICKER)/db/kicker.db","PVPREFIX=$(MYPVPREFIX), ,P=$(MYPVPREFIX)$(IOCNAME):,DAQMX=$(MYPVPREFIX)$(IOCNAME):DAQ:, PSU_MAX_CURR=$(PSU_MAX_CURR=15),RECSIM=$(RECSIM=0),DISABLE=$(DISABLE=0),PORT=$(DEVICE)") | ||
| dbLoadRecords("$(KICKER)/db/kicker_voltage.db","PVPREFIX=$(MYPVPREFIX),P=$(MYPVPREFIX)$(IOCNAME):,RECSIM=$(RECSIM=0),DISABLE=$(DISABLE=0),PORT=$(DEVICE),DAQMX=$(MYPVPREFIX)$(IOCNAME):DAQ:,IFNOTRECSIM=$(IFNOTRECSIM),IFRECSIM=$(IFRECSIM),PSU_MAX_VOLT=$(PSU_MAX_VOLT=45),NELM=$(NELM=1000)") |
There was a problem hiding this comment.
Related to the comment about letting the user set F and N in the st-daq.cmd, there is already a macro here which appears to set N, NELM. I think this may get confusing though, as the end users might not understand what this means/refers to.
…ro and the Frequency of sampling as a macro
…71_Add_IOC_KICKER
Description of work
To test
#3404
Acceptance criteria
Code Review
Functional Tests
..._0nwheren>1) run correctlymacLib: macroto find instances ofmacLib: macro [macro name] is undefined...Final steps