Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unknown Property "level" #66

Open
Johannes-Thiel opened this issue Sep 5, 2024 · 2 comments
Open

Unknown Property "level" #66

Johannes-Thiel opened this issue Sep 5, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@Johannes-Thiel
Copy link
Collaborator

there seems to be a issue regarding the level property. This has been observed on the mini robot z33 and on the f15.

 read: I (2450) gpio: GPIO[34]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
2024-09-05 11:41:52.975 [DEBUG] rosys/hardware/communication/serial_communication.py:72: read: I (2450) gpio: GPIO[35]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
2024-09-05 11:41:52.985 [DEBUG] rosys/hardware/communication/serial_communication.py:72: read: I (2470) gpio: GPIO[39]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
2024-09-05 11:41:52.995 [DEBUG] rosys/hardware/communication/serial_communication.py:72: read: error while loading startup script: unknown property "level"@08

Due to this error, there is no core output.

@falkoschindler
Copy link
Collaborator

We noticed a similar problem. I suspect you're using a level property on a port expander inside a rule. PR #51 should have fixed the problem with properties being evaluated too early, so we removed the workaround for level and active. But it turned out that when compiling a property expression, the property is still accessed in order to retrieve its data type.

A workaround (and maybe the only valid solution) is to add properties explicitly before defining rules:

button = p0.Input(42)
button.level = 0
when button.level == 1 then do_something(); end

@falkoschindler
Copy link
Collaborator

This issue will be solved by #18:
"When instantiating a proxy module, the execution should wait until the expander has sent a first broadcast message."

@falkoschindler falkoschindler added the bug Something isn't working label Sep 5, 2024
pascalzauberzeug added a commit to zauberzeug/field_friend that referenced this issue Oct 21, 2024
Add fix for zauberzeug/lizard#66 for the
tornado.

---------

Co-authored-by: Pascal Schade <pascal@zauberzeug.com>
Co-authored-by: Pascal Schade <165774906+pascalzauberzeug@users.noreply.github.com>
pascalzauberzeug added a commit to zauberzeug/field_friend that referenced this issue Oct 23, 2024
We still notice issues with
zauberzeug/lizard#66 (`Unknown Property
"level"` and `Unknown Property "active"`) until then setting them to 0
and false on p0 helps.

Depends on zauberzeug/rosys#216
Johannes-Thiel pushed a commit to zauberzeug/field_friend that referenced this issue Nov 14, 2024
This PR fixes the weeding screw until
zauberzeug/lizard#66 is fixed. Like
#213 did it for the
tornado.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants