If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
deleted by uploader
7 posts
• Page 1 of 1
deleted by uploader
deleted
Last edited by tiffy on Mon Aug 24, 2015 7:58 pm, edited 1 time in total.
-
tiffy - Posts: 400
- Joined: Wed May 08, 2013 12:14 pm
deleted by uploader
deleted
Last edited by tiffy on Mon Aug 24, 2015 7:58 pm, edited 1 time in total.
-
tiffy - Posts: 400
- Joined: Wed May 08, 2013 12:14 pm
Re: Switching Target On/Off from Different Locations
Unsure if this is what you mean o.O
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe."
Albert Einstein
Albert Einstein
-
JB_AU - Posts: 171
- Joined: Tue May 21, 2013 11:01 pm
deleted by uploader
deleted
Last edited by tiffy on Mon Aug 24, 2015 7:58 pm, edited 1 time in total.
-
tiffy - Posts: 400
- Joined: Wed May 08, 2013 12:14 pm
Re: Switching Target On/Off from Different Locations
Maybe I misunderstand the intent, but surely it's simpler to just send wireless triggers to a common toggle?
The trouble with multiplexers is this - when you change the index, only the newly selected output sends a trigger - the unselected ones don't, and so the 'old' output doesn't update its value - unless a trigger from somewhere else forces it to. It might seem odd, but your ticker isn't actually doing anything much to the Selector - it's really causing the Multiplexer to be 'asked' for its correct output value (often described as an 'invisible backwards trigger'!).
In the schematic above, you can see one way to try and overcome this (there are others depending on the application).
The key here is the order that you make links from the index selection, so that a reset value gets sent to the current selection, then the selection changes, then the new value is triggered.
Although it is quite a bit more complex, it is much better for performance - unless they get blocked somehow, the triggers from the 'tick 25' will find their way along links and all over the following parts of the schematic, which can cause unintended effects, and will suck CPU (especially if they cause screen redraws).
Another way would be to extract the trigger from the selection and just send it to all of the outputs to update them all (NB - a module with only a Trigger in -> Trigger out is one of the most useful ever - use it to grab only the triggers from any kind of 'green' link).
However you do it, you can often improve things with a few "changed" primitives to clean up any extra triggers that aren't really needed.
tiffy wrote:a better method than the "Tick 25 primitive" I used to allow signal flow to pass through the Multiplexer/Selector combination ??
The trouble with multiplexers is this - when you change the index, only the newly selected output sends a trigger - the unselected ones don't, and so the 'old' output doesn't update its value - unless a trigger from somewhere else forces it to. It might seem odd, but your ticker isn't actually doing anything much to the Selector - it's really causing the Multiplexer to be 'asked' for its correct output value (often described as an 'invisible backwards trigger'!).
In the schematic above, you can see one way to try and overcome this (there are others depending on the application).
The key here is the order that you make links from the index selection, so that a reset value gets sent to the current selection, then the selection changes, then the new value is triggered.
Although it is quite a bit more complex, it is much better for performance - unless they get blocked somehow, the triggers from the 'tick 25' will find their way along links and all over the following parts of the schematic, which can cause unintended effects, and will suck CPU (especially if they cause screen redraws).
Another way would be to extract the trigger from the selection and just send it to all of the outputs to update them all (NB - a module with only a Trigger in -> Trigger out is one of the most useful ever - use it to grab only the triggers from any kind of 'green' link).
However you do it, you can often improve things with a few "changed" primitives to clean up any extra triggers that aren't really needed.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
Don't stagnate, mutate to create!
-
trogluddite - Posts: 1730
- Joined: Fri Oct 22, 2010 12:46 am
- Location: Yorkshire, UK
deleted by uploader
deleted
Last edited by tiffy on Mon Aug 24, 2015 7:59 pm, edited 1 time in total.
-
tiffy - Posts: 400
- Joined: Wed May 08, 2013 12:14 pm
Re: Switching Target On/Off from Different Locations
Here is a simple way to have one Boolean output controlled from various sources (on/off switches) which are synced. Turning on/off one led updates all the others. You may put preset manager into the master switch module or any of the LEDs and it should work just fine.
- Attachments
-
- Remote_grouped_on_off.fsm
- (26.29 KiB) Downloaded 1073 times
- KG_is_back
- Posts: 1196
- Joined: Tue Oct 22, 2013 5:43 pm
- Location: Slovakia
7 posts
• Page 1 of 1
Who is online
Users browsing this forum: Google [Bot] and 66 guests