03-16-2021 07:24 AM
you're right, meanwhile I noticed running in the error without noticing previously..
now I noticed, grrrrrrrrrr
annoying to put all this task into one change detection and at the event finding out, which one caused it... could be easier...
03-16-2021 08:49 AM
so, next issue (I ran from error to Error)
I changed the initialization to
If I try to read the Inputs in an later stage, I got an timeout:
any suggestions why?
03-16-2021 10:05 AM
Can't tell without more info. Generically, there weren't enough changes detected to supply you with whatever # samples you asked for. Could be a signal problem, a physical wiring problem, a timing problem (trying to read samples before changes start), a simple coding problem (requesting too many samples). And more possibilities.
-Kevin P
03-18-2021 05:45 AM
so, it still don't work
in the previous version i tried to read out the same channels I defined as trigger for an Event.
so i changed this to Inputs I only defined for the event:
and the same (wired into to different inputs):
if I press one of the buttons, I can see the system notice this but the Event does not trigger.
I don't get the reason why?
03-18-2021 06:18 AM
Honestly, I think you'd be very well served to take two steps back from your relatively complex overall application and focus on a few details in small bite-size pieces.
Let's focus on the change detection stuff first. Start a brand new vi. Include *only* a single DO task with only your single E-stop input, which is apparently port0/line25. Configure the task for change detection and register for a user-defined event.
Make an event handling loop that has event cases for *only* this change detection event and a GUI stop button. Basically, limit yourself to exploring the most basic level of functionality first. If you have trouble with this simpler example post your *actual code*, not just screenshots of parts of the code. But if you do it right, and it works, come on back and we can discuss why the approach you took in the latest posting *didn't* work.
-Kevin P
03-18-2021 09:28 AM
looks like thought transference, I was so annoyed I build basic functions to get it working.
(if this is the wrong location for this topic i can post elsewhere)
so the trials are:
I Have a switch at Line 25 and 27, I want to have an event if I press one of them, Best Case two separate events.
first one:
I got an Event when pressing the button at line 25, but none when pressing those at line 26
same here:
and here:
how do I get an Event at pressing either Button at line 25 or 27?
(offtopic if anyone knows: any solution for bouncing correction? by pressing the switch I get 15-20 Events)
03-18-2021 10:24 AM
and this does not work either:
(i got an Event at pressing the button at line 25 but not when pressing the button at line 27)
03-18-2021 10:44 AM
Remember how I suggested you make just 1 task with just 1 digital line? None of your 3 approaches do that. Instead you got into various problems I was trying to help you avoid. (Don't worry, they aren't going away, you'll get your chance to tackle them later.)
Now, let's consider your first approach. When you configured Change Detection on your task, you told it to be sensitive *only* to line25. And so only line25 caused an event to fire. Not much more to be said about that one.
Note also that you don't need a loop to put 2 channels into 1 task. You can right-click a single channel constant, select "Browse...", then use standard conventions like Shift-click to select a range or Ctrl-click to add items separated from one another in the list.
Your other 2 approaches attempt to create 2 separate change detection tasks. Your device won't be able to support that, as I already mentioned back in msg #10.
Switches with a lot of bounce may add a whole other level of difficulty. For starters, I'm not sure whether you'll get a distinct software user-defined event for every hardware change detection event. It isn't something I've tested at various hardware change speeds.
And frankly, you probably shouldn't *want* that burst of pre-steady-state software events. The presence of so much bounce would lead me to a different approach.
Here's one that comes to mind: one digital change detection task, but don't register for the change detect signal event. Instead, monitor your digital change detection task in an independent loop. Figure out your method for identifying the final steady digital state at the end of any bounce. When you see that a change is stable, *then* fire one single software event after the bouncing is all done.
-Kevin P
03-22-2021 03:57 AM - edited 03-22-2021 04:07 AM
Thanks!
that was the solution!
this works!
I thought the Change detection accepts only one input, so I didn't try several ones...
regarding the bouncing:
I think I'll try an electronic solution by a schmitt-trigger (e.g. that one :https://www.mikrocontroller.net/articles/Entprellung), the software version will be complex and not so failure resistant as it requires...
Thanks for your help!!!
06-08-2021 06:16 AM
Hello Together,
regarding the bouncing i've an update.
even with the trigger i sometimes i got two events.
to avoid that i created an software debouncing:
time comparison VI:
in the event structure:
if an event occurs i take the current timestamp and save this into the shift register
next time an event happens, i compare both times.
test with bouncing elements showed that those created times around 0 - 1ms
manual switching times were about 180 - 500ms,
so i choose to ignore anything below 150ms
(maybe this helps another one avoiding the same issue)