KickUI: a GUI tool to inspect, configure and operate an EtherCAT bus#411
KickUI: a GUI tool to inspect, configure and operate an EtherCAT bus#411leducp wants to merge 1 commit into
Conversation
leducp
force-pushed
the
kickcat_kickui
branch
2 times, most recently
from
26f6c2c to
6cb2fb2
Compare
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against e2aa3b0 |
There was a problem hiding this comment.
I think bunch of definitions is this file are already defined in other regions of the existing codebase, I would suggest reusing those defs or maybe adapt them to fit the need?
| { | ||
| namespace | ||
| { | ||
| constexpr uint16_t DS402_PROFILE = 402; // low word of 0x1000 device type |
There was a problem hiding this comment.
I think we need to find a way to fill the profile catalogs, that way the bus session is agnostic of the potentially ever growing slave profile list
There was a problem hiding this comment.
But we will still need to own the supported profiles somehow.
| // (getTopology). Runs on whichever thread currently owns the bus. With | ||
| // refetch the DL status is re-read from the wire first (live refresh); | ||
| // at connect time bus.init() has already populated it. | ||
| TopologyInfo computeTopology(Bus& bus, bool refetch) |
There was a problem hiding this comment.
Do we not already have a method that does this somewhere else? If yes I think we should refactor and mutualise.
There was a problem hiding this comment.
There is and it is used here (cf line 62). This computeToplogy is a wrapper around the tree walk algorithm to add all infos needed by the UI in the answer
| bool Device::isOperating() const { return session->isOperating(index); } | ||
| std::shared_ptr<MotorControl> Device::motor() const { return session->motor(index); } | ||
|
|
||
| void BusSession::connect(std::string const& interface) |
There was a problem hiding this comment.
I think the bus latency timeouts should be param, as kickui does not need to be hard realtime, we can have slow masters (non rt kernel) for diagnosis
There was a problem hiding this comment.
Well, it is not true: Marvin robot for instance need DC and a proper real time. The UI do need to at least 'try' to reach a proper good enough real time.
About the timeout param though I'll do a check because there is a param.
| try | ||
| { | ||
| bus->readSDO(slave, 0x1000, 0, Bus::Access::PARTIAL, &device_type, &size, 100ms); | ||
| dev.is_ds402 = ((device_type & 0xFFFF) == DS402_PROFILE); |
There was a problem hiding this comment.
I think we need to rework this, right now we only have ds402 but maybe in the future we might have other profiles
There was a problem hiding this comment.
Agree: this flag is too specific.
| return; | ||
| } | ||
| LockGuard lock(controls_mtx_); | ||
| std::shared_ptr<MotorControl> dc; |
There was a problem hiding this comment.
Change DC to motor or something else, I confused it for distributed clock
There was a problem hiding this comment.
hahaha right now that I re-read it without the context it is quite disturbing
KickUI is an imgui/glfw bench tool built on the KickCAT master. It connects to a real NIC or to the embedded software simulator (tap), scans the bus and shows the discovered topology as a drawn graph (DL_STATUS port states, cable break/heal on the simulator), per-slave diagnostics (AL states, error-counter totals, event log with alert banner) and a per-device detail view: SDO transfers and object-dictionary discovery, PDO mapping read-back and manual editing, live process-data bytes, and full DS402 drive control (bring-up, state machine, manual/jog/generator setpoints). Rework README to lead with stack capabilities and move build, hardware, simulation, tooling, and performance instructions into dedicated docs/ files.
2 participants
KickUI is an imgui/glfw bench tool built on the KickCAT master. It connects to
a real NIC or to the embedded software simulator (tap), scans the bus and
shows the discovered topology as a drawn graph (DL_STATUS port states, cable
break/heal on the simulator), per-slave diagnostics (AL states, error-counter
totals, event log with alert banner) and a per-device detail view: SDO
transfers and object-dictionary discovery, PDO mapping read-back and manual
editing, live process-data bytes, and full DS402 drive control (bring-up,
state machine, manual/jog/generator setpoints).