slaclab / epics-ek9000 Goto Github PK

Currently you need to run ek9000DumpMapping from within iocsh to get a terminal mapping. This is a bit annoying, and it'd be nice if terminal mapping info could be exposed via a custom PV structure using pvxs. Then pvinfo could be used to query the terminal mapping. bsaDriver takes the same approach for the BLD_PAYLOAD PV.

Looks like the EL3314 is missing LINR field and some other defaults in the generated template file.

The analog input terminals provide some status information such as Limits, overrange, underrange, error, etc. which could be used to set alarms accordingly.

These terminals have no PDOs but still show up in the bus layout register, which might screw up mapping. These just need to be skipped when computing terminal mapping.

The manual contained in this repo needs updating. Ideally entirely new documentation should be written following the pattern of PCDS documentation.

Some topics that should be covered in the new documentation (in no particular order):

• Compiling the module
• Setting up an IOC
• Limitations
• List of supported terminals
• Commissioning terminals: Basic instructions, selecting the correct PDO mapping
• Commissioning analog terminals: supported presentations, configuring for alternative presentations (i.e. MSB)
• Commissioning motor terminals: supported PDO types, limitations, etc.
• Adding support for new terminals: details of PDO type safety system, etc.

Issue

EL3062 records such as:

Have .PREC default to 0.
Clients like Grafana take a precision setting of 0 to mean "display as an integer" - which is rarely what we want.

Path forward

For now, .PREC appears to be autosaved and can be customized by the user without much issue - on a channel-by-channel basis.

Fields

• I think it might be wise to set a sensible precision for analog input records
  • You could calculate a good number for these based on the ADC resolution, but really a precision of 3 would probably be fine
• Additionally, deadband settings for monitoring and archiving should probably be set
  • This is a bit tangential so it's a topic for another issue (https://epics.anl.gov/base/R7-0/6-docs/aiRecord.html ; see Monitor Parameters)

There's an edge case with the STATIC_ASSERT macro provided by EPICS when building with C++03 and earlier. Specifically when STATIC_ASSERT appears in global scope in an included file on the same line number as a function-scope STATIC_ASSERT in a different file.

PR: epics-base/epics-base#401

We'll probably never be able to enable -Werror=shadow in normal builds again, for compatibility reasons. But for BUILD_STRICT in CI, that's fair game after the aforementioned fix is merged.

The EL7047 provides the required connections for basic encoders, but it does not provide any interface for SSI/BISS-C/other encoders.
A simple iocsh function (e.g. el70x7SetEncoder) could be used to associate an encoder terminal (EL50XX terminals) with the motor controller.

I suggest adding an ArraySize template like this to handle that:

template<class T, size_t N>
size_t ArraySize(T(&arr)[N]) {
    return N;
}

Should work in old C++ standards too

Originally posted by @JJL772 in #19 (comment)

Need to write a header that contains some "portability" utils for older C++ versions:

• static_assert macro
• nullptr macro
• for loop macros (maybe?)
• error out on auto keyword use (before C++11 auto meant "automatic storage lifecycle")

Other things:

• build with C++98 in makefiles

Terminal template files currently have records for every channel on the device, and use the same base name for each channel. This isn't ideal, as you need to provide an alias if you want to use different base PV names for each channel.

Single-record templates should be in the form ELXXXX_1.template

Terminals should be associated with a terminal by means of an input link string.
A good way to do this might be: IP:port@1:1, where IP is the ip, port is the port, the first 1 is the slave number and the second 1 is the channel number.
This would be ideal for easily configuring the terminals, without needing IOCsh functions.

CoE configuration could be done via longin, longout, bi, bo, etc. records with a special device type called CoE or something along those lines. They could then be linked by means of the input link string, possibly formatted like this: terminal-record:parameter or terminal-record:index:subindex

It should be 8 bytes instead of 6.

0x1A00 and 0x1A01 are the relevant PDO assignments

Device times out periodically and causes ADC values to go to max raw counts, and causes DAC value to go to zero.
- Seems to be caused by a fast scan rate on PVs (defaults to 0.1s)
- Behavior is erratic, non-periodic, and has different time intervals across different systems
- Current solution: set scan rate to 1Hz (in iocsh), set watchdog timeout to 60s (in web interface), set Fallback mode to "Freeze" (in web interface)
- Not sure what the effects of the watchdog timeout are, I may be misinterpreting that
- The Fallback mode - "Freeze" is supposed to retain the last know values of registers instead of resetting them to max or zero, but this doesn't seem to work correctly every time
- Setting scan to 1Hz has helped and we are no longer seeing these timeouts
- PVs that aren't being used or are set points have been set to "Passive".
- The system where we see this issue (all of them) have between 8-300 PVs scanning at 10Hz which causes this issue, the lower is end of PV counts is quite low
- Modbus is slow but shouldn't be that slow, compare to BK9000 where this issue is not seen (AIN proc at .1s with many more PVs per device)
- *.SCAN field needs to be autosaved for all PVs

CI is a bit unstable for some reason.

Unfortunately it's quite easy to have a mismatch between terminal PDO size and structs declared in code. I've found a couple instances of this with EL5042 and some of the analog input terminals.

A macro like this should do:

DEFINE_SINGLE_CHANNEL_INPUT_PDO(type, terminal);
DEFINE_SINGLE_CHANNEL_OUTPUT_PDO(type, terminal);

We can enforce macro usage by generating an externed symbol for each terminal, which is then defined by the aforementioned macros. A generated function static void __PDO_Hack() (or something similar) would then set all of those extern'ed symbols to 1. That function would then be called from a non-static, non-inline global function in devEK9000.cpp. Any terminals without an associated PDO type would then generate a linker error.

There might be better ways to do this using C++11 features like constexpr, but we do need some C++03 support unfortunately.

find_terminals.py

On a per-entry level, the above is correct. However, I incorrectly assumed the EK9000 support was taking the PDO size and multiplying by the number of channels, which it is clearly not:

The correct value should be the sum of the individual entries.

Additionally - the recently-added EL2794 at least should be modified based on the above.

Mappings?

I've also found that it is easy to change slave mappings via the web interface, which we should document:

The "proper" way to specify a terminal seems to really require the following information, of which only (1) is currently used:

1. Terminal name
2. Revision number
3. Slave mapping setting

I think the above could be pretty easily autogenerated, but doing it in a backward-compatible way may be difficult. And it'd be a pretty long list...

Something broke between ioc/common/ek9000/R1.1.2-0.2.0 and ioc/common/ek9000/R1.2.0-0.1.0
- All INP and OUT fields of all records are processed as "CONSTANT" with the new parent IOC
- as a result, even with the IOC operational and all records processed, no data is being transferred to/from the EK9000
- did some digging and could not find the root cause, instead I have a kluge'd version of the old device support running with added terminals
- These two parent IOCs use different device support modules

This results in alarms never being cleared.

If a fault occurs during a terminal's initialization or operation, the device's E-Bus status is set to "Error". When in this state, the device will reject all I/O to the process data address space (status registers still work just fine)

The module does not handle this state well (or at all..) and will continuously attempt reads. We'll probably want to check E-Bus status when the status registers are read, and skip any I/O when in an error state.

A few things rely on the int64 record, but they can be considered optional (ex: EL5042 support)

Some labs are using older versions of EPICS, so we might want to consider ifdefing out code that only works on 7.0.
There shouldn't be too much that relies on 7.0 anyway.

Note: This feature already exists in the asyn/motor support branch of the module, but only for the EL7047 and related devices.

Add an iocsh command that will allow users to configure the various CoE parameters for slaves connected to the EK9000.

Examples:

ek9kSetCoEParam(EK9K, terminal number, coe param by name, new value)

Each terminal type would supply a pointer to an array of coe parameter types. The CoE parameter type struct would look like this:

struct coe_param_t
{
    const char* name;
    const char* desc;
    int index;
    int subindex;
    int data_type; /* COE_TYPE_INT16, COE_TYPE_INT8, COE_TYPE_BOOLEAN, COE_TYPE_STRING, etc. */
    int length; /* Only for string data types */
}

Will debug this more later, could be something I've done locally in my environment.

Everything works as intended when using asyn R4-39, but I get a crash in asynTrace on latest asyn version.

Adding device support for:
- EL4104
- EL4134
- EL4114
- EL3681
- EL3314
- EL3318
First 4 modules have existing support in /reg/g/pcds/epics/R7.0.2-2.0/modules/ek9000/R1.2.0-0.1.0, see related issue #6 where input output links are broken for latest device support

In many cases it may not be desirable to generate individual records for each channel on a device, especially for something as simple as digital I/O.

mbbo and mbbi record support should be added to the module for EL1XXX and EL2XXX device support types. These records support up to 16 channels per record, which can majorly reduce clutter.

Support is currently WIP on the enh_mbbi branch on my fork.