Printable View
That shouldn't be difficult to do at all, Gary. That's like an extremely simple program as far as I can see. I need to get into the swing of linux programming and learn dbus but I could probably even write that. You can probably write it on your own.
Yeah, it's simple, I'm just lazy. And given only a finite amount of time, I would rather work on my little project than a throwaway tool to experiment with said little project.
Gary (-;
Wrote the sample sim app. Chunky knows where I hid it.
PaulIF, if fbd crashes without a fusion brain hooked up, we need to do something about it. When I get some more time, I'll test more...
kev000, just FYI it won't reconnect if the FB gets reset or power cycled either.
Also, I checked in a small fix the other day to stop a divide by zero on stupid user input too.
Updates...
Has a version been released which solves the problem of the fusion brain coming unplugged then plugged back in?
--------------------------------------------------
Bug...
It appears that it doesn't cue up commands perfectly. I have a multi-threaded app calling it.
This is in python...
Turning on/off outputs is done by two functions in my app.
I need commands to be fired in separate threads since this gets controlled via the web and response time is critical.
So each function calls the dbus command on a thread of its own so that the functions can return instantly.
This works perfectly if I'm just turning off/on 1 output. However today, I finished adding all my accessory lights. Lights are now on 3 ports. If I turn all three on/off sequentially...
turnOff(8)
turnOff(9)
turnOff(10)
3 threads are fired up and all attack the dbus at about the same instant. I'd say about 40% of the time, one does not turn on/off properly. Putting a wait in between works but uses valuable time. Any ideas?
--------------------------------------------------
Feature request...
Is it possible to make a function which returns whether an output is on or off?
I solved this by having fbd automatically launched by udev whenever it detects a FB plugged into USB, and automatically killing fbd whenever that device disappears from USB. I hope to have it all polished by this weekend, at which time I plan to document it on my blog and here, and hopefully make a .deb available.Quote:
Originally Posted by PaulF
I've been working on advancing fbd some, and have successfully set up the method setMaskedOutput(low,high,lowmask,highmask). It works like setAllOutput(low,high) but uses the masks to only alter the outputs where '1' bits appear in the pertinent mask. So setMaskedOutput(255,255,128,127) would use low and high to set outputs 8-14 on, and leave 1-7 and 16 unchanged. It's not precisely what you're requesting, but can pretty easily be used to achieve it. Your example of turning off 8,9,10 can be achieved with "setMaskedOutput(0,0,128,3)".Quote:
Originally Posted by PaulF
The problem you're encountering is caused because setSingleOutput() actually reads the state of all 16 outputs into an array, alters the state for the single selected output, then sets all 16 outputs to what is in the array. If you fire off multiple setSingleOutput()s close together, then you have a problem arise where the last one reads current state (which doesn't always include the other changes still running) and alters only its own selected output. I've not yet seen a simple solution that would avoid the race condition you're encountering, given multiple near-simultaneous set commands. (apart from using my new setMaskedOutput and ensuring that you do NOT have multiple near-simultaneous commands)
I've also added method getSingleOutputState(ionum), which returns either 0 or 1 indicating the state of the queried output. I still want to get a 'getOutputState()' working that returns state of ALL outputs at once.Quote:
Originally Posted by PaulF
Regardless of that last bit (getOutputState()) I plan to post my updated sourcecode (and hopefully a .deb package) this weekend.
If anybody has any other suggestions or requests let me know now, I'm not really intending to maintain fbd indefinitely, just make some useful alterations and additions and return it to the community.
j
Clever solution, I always forget how cool udev is.Quote:
Originally Posted by newkirk
Nice. Right now my solution was to call each method 3 times. I've had it fail once over the course of the month which is pretty good, but certainly not the right way to do it. This is perfect. Thank you!Quote:
Originally Posted by newkirk
That explains it. I should have poked around in the source.Quote:
Originally Posted by newkirk
Now, is this just tracking the outputs as far as FBD knows it, or is it actually querying the hardware? Ex. If the fusion brain is plugged in and the computer restarts, the outputs that were on before will still be on when restarted. If it's not possible to query the hardware directly, the FBD should set all outputs to off when it is started to prevent it from having inaccuracies.Quote:
Originally Posted by newkirk
Thanks a ton. Awesome first post. Welcome to mp3car, you're a great addition to the forums here!
Try this in /etc/udev/rules.d/99-fusionbrain.rules or /lib/udev/rules.d/fusionbrain.rules (change /usr/local/bin/fbd path as needed):Quote:
Originally Posted by PaulF
This does NOT start fbd on boot though, only on insert/reinsert - I've not looked into it too much yet, but suspect it's because udev starts LONG before dbus. In any case, since I've got an init script for other stuff anyway, I just put "/sbin/udevadm trigger --attr-match=idVendor=04d8" in there, which tells udev to trigger an 'add' event for any matching device. Just ensure that script runs after dbus is started.Code:
ACTION!="add", GOTO="fb_rules_remove"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GOTO="fb_add"
SUBSYSTEM!="usb_device", GOTO="fb_rules_end"
LABEL="fb_add"
ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="000e", RUN+="/usr/local/bin/fbd >/dev/null 2>&1 &"
LABEL="fb_rules_remove"
ACTION!="remove", GOTO="fb_rules_end"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GOTO="fb_remove"
SUBSYSTEM!="usb_device", GOTO="fb_rules_end"
LABEL="fb_remove"
ENV{ID_MODEL}=="Fusion_Brain", RUN+="/usr/bin/killall fbd"
LABEL="fb_rules_end"
It's querying the FB hardware. The method setSingleOutput() reads in an array of data from the FB over USB, overwrites the single value you've set, then writes the array back to the FB. I just read that array in and parse it to return the value for the selected output.Quote:
Originally Posted by PaulF
Thanks. Once I've figured out the most useful way to return the state of all 16 outputs simultaneously (I'm thinking about a 16-character string with 0 and 1 - easy to output, easy to parse in bash or whatever else), and cleaned up the code a bit, I plan to post the modified source (and hopefully a .deb) back here. Anyone with permissions is welcome to fold my augmentations back into the official source in svn. One thing I intend to change, but which would break legacy usage, is to number inputs/outputs starting at 1 instead of 0. When I send a dbus command to turn on output 1, I expect the output labeled as '1' on the board to be switched, not the one labeled '2'...)Quote:
Originally Posted by PaulF
j
Awesome.Quote:
Originally Posted by newkirk
While this seems logical from a human perspective, it is illogical from a programming perspective since arrays start at 0. Most things of this nature also start at 0.Quote:
Originally Posted by newkirk
Good idea. If you can prepare a patch, i'll apply it to the mainline fbd.Quote:
Originally Posted by newkirk
What about a byte array or an array of (int/double)? dbus supports those types and it's a bit more specific than a string to the app requesting it.Quote:
Once I've figured out the most useful way to return the state of all 16 outputs simultaneously
PaulF: Can you describe the multi-threading problem in more detail. i can't think of why it wouldn't "just work" off the top of my head...