Comments (11)
The workaround via add_heartbeat_callback()
(now spelled correctly in the latest release) is a perfectly valid solution IMHO. I assume you have configured the device to send heartbeats regularly. So you will get some heartbeats with state "INITIALISING" while your setup is not yet finished. Once the received heartbeat actually indicates "PRE-OPERATIONAL", you know it's not the automatic promotion happening to the node.nmt.state
property.
It basically all hinges on the fact that your node sends at least one more heartbeat after the initialization, which is not guaranteed by the protocol unless you have configured the Heartbeat Producer Time in advance.
from canopen.
I’ll admit I’m not familiar with whether or not this proposed change will cause issues for others or cause other issues, but a solution to your existing problem could be to use the existing “add_heartbeat_callback()” function to set up your own callback function. This appears to get called before the state is modified, so you’ll get a notification of booting.
Edit: Per another open issue, there is a typo in that function name to watch out for, it’s actually currently “add_hearbeat_callback”.
from canopen.
The issue for the typo is #389
from canopen.
Copied from #402
I see the need to have a "synchronized" state hassle-free. Maybe we can introduce some option for the node, which enables state transitions based on the heartbeat only. Because I think it is a very commong use-case to wait for a device until it finished its internal startup. Currently in my older mc-test projects I use a fixed waiting time, which is bad. In the newer tests, I subscribe to the heartbeat to do another is-ready check, but this would be so much easier if I just could enable this behaviour on the node itself.
from canopen.
I agree with André that using add_heartbeat_callback()
is a usable API for this use-case. A short how-to in the docs should be enough.
from canopen.
I see the need to have a "synchronized" state hassle-free.
The problem is that it won't help unless one has manually convinced the device to send another heartbeat. The only required NMT message is the boot-up message with state INITIALIZING. The further transition to PRE-OPERATIONAL is implicit, that's why the code handles it appropriately. It is perfectly valid to assume it has already occurred (past tense), as the spec says (emphasis mine):
7.2.8.2.3.1 Service boot-up Event
Through this service, the NMT slave indicates that a local state transition occurred from the NMT state Initialisation to the NMT state Pre-operational.
Now if a device sends its boot-up message before in fact being "ready", that's a different problem. I see two ways to mitigate it, either put a delay on the master side, or wait for the next heartbeat which states PRE-OPERATIONAL. But note that the device has no obligation to send another NMT heartbeat object upon the state transition. It will only send another after the Heartbeat Producer Time parameter has been set (and saved) in the device. If it could be enabled immediately via SDO, then we wouldn't have a problem ("device not ready") in the first place. This parameter needs to be chosen to a fixed interval, which is consequently the worst-case time until we get another heartbeat. So instead of doing that and waiting for an appropriate heartbeat, we could just as well choose the first option and hard-code the delay on the master.
This really only concerns broken device behavior and I'm pretty sure there is no more efficient way to work around it. Getting the boot-up message means the device already is in PRE-OPERATIONAL. If it doesn't behave as desired in this state, that doesn't invalidate this fact.
from canopen.
So instead of doing that and waiting for an appropriate heartbeat, we could just as well choose the first option and hard-code the delay on the master.
Why a delay? What would that solve? How could you even pick a sensible delay value? I would prefer the status quo rather than introducing an arbitrary delay.
from canopen.
This really only concerns broken device behavior and I'm pretty sure there is no more efficient way to work around it.
Ok sounds reasonable. We have a working solution, but we should really provide documentation for it.
I would prefer the status quo rather than introducing an arbitrary delay.
Same, an arbitrary delay is a no-go in a (general) framework.
from canopen.
I think there is consensus that this is a documentation issue. What remains is a docs PR. I can try to cook up something within a day or two, unless someone else beats me to it.
from canopen.
I'm not arguing for introducing a delay in the canopen library. Instead, the application-level workaround which @friederschueler described above and which I think is common:
Currently in my older mc-test projects I use a fixed waiting time, which is bad.
I had a project where we needed to wait ~2 additional seconds before SDOs would work (on a Nanotec CL4-E controller). That's one reason for me to make sure configuration is saved in the device during commissioning, and doesn't need SDO communication after each power-up.
How could you even pick a sensible delay value?
How would you pick a sensible Heartbeat Producer Time value? I was just saying that without that being set, you won't get any further heartbeat. So the time you pick there is just as arbitrary a minimum delay as if you had added the delay in your application code.
from canopen.
Why a delay? What would that solve?
I think these questions clearly show that some experience with CANopen in general is needed to write a correct documentation entry for this issue. I don't have the time now to write up something, but will happily review a rough draft and offer my experience to beat it into shape.
from canopen.
Related Issues (20)
- The `node_id` parameter of `import_od` is not saved to the resulting OD object
- Give deprecation warning on old interfaces HOT 3
- Rename RemoteNode.load_configuration() HOT 11
- Support canfestival OD-files? HOT 6
- An empty file is created if an unsupported doc type is passed to `export_od()`
- Consider bumping the `python-can` minimum required version to 4.0 HOT 12
- `PdoBase.export()` is broken bco. broken dependencies HOT 4
- examples/simple_ds402_node.py uses contradictory PDO mapping patterns HOT 3
- Test docs build in CI HOT 2
- `NmtBase.state` should always return a `str` HOT 11
- pytest fails on master due to TestEDS.test_export_eds_to_file HOT 1
- Type annotation of Mapping in Python 3.8 HOT 2
- Purge workaround for docs build HOT 6
- Network instance is optional in many classes, which requires lot of checking HOT 4
- Improve test coverage
- getting weird behaviour with sdo read and heartbeat callbacks on 2.3.0 HOT 1
- `network.PeriodicTask.update` fails to update periodic RPDO HOT 1
- Object Dictionary does not get updated HOT 1
- PDO Receive Issue
- Reduce network shutdown latency HOT 20
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from canopen.