A problem with outputs

If you have a question about the software please ask it here.

Re: A problem with outputs

Postby Robertspark » Sat Oct 13, 2018 4:27 pm

Why are you using exec.wait?

Everything stops for wait.

Use sleep.... That way the loop will not stop but check back to see if sleep time has passed

https://docs.microsoft.com/en-us/dotnet ... work-4.7.2
Robertspark
 
Posts: 1892
Joined: Sat Sep 03, 2016 4:27 pm

Re: A problem with outputs

Postby Robertspark » Sat Oct 13, 2018 4:29 pm

Exec.Wait is like / same as G4 pxxx.

Everything waits and stops for that time to pass
Robertspark
 
Posts: 1892
Joined: Sat Sep 03, 2016 4:27 pm

Re: A problem with outputs

Postby Robertspark » Sat Oct 13, 2018 5:39 pm

???
Is it fixed now or did you want to use wait?
Robertspark
 
Posts: 1892
Joined: Sat Sep 03, 2016 4:27 pm

Re: A problem with outputs

Postby Robertspark » Sat Oct 13, 2018 8:40 pm

Vmax549 wrote: From time to time I see ODD things occuring when I use Thread.Sleep(). From what I see wait only effects teh thread you are running?? And in this case teh Wait() is stone dependable.


I suspect that wait is more accurate because it waits until the time has passed, however, sleep will poll the time intermittently .... And is subject to whatever else is running in the background and however long it gets hung up before it can poll the time again (I don't know but it's just a guess)
Robertspark
 
Posts: 1892
Joined: Sat Sep 03, 2016 4:27 pm

Re: A problem with outputs

Postby Dan911 » Sat Oct 13, 2018 10:42 pm

I've read using Thread.Sleep() or wait() are poor and unstable solutions to thread syncing and there are many other reliable wait handles preferred. In most cases it can case more harm than good, I now refrain from using them. If used it's Thread.Sleep, I came across more than 1 instance's I seen wait() ignored. I also read using sleep/wait is poor programing.

Don't shot the messenger!!!!! Only relaying what I read.

Dan
Dan911
 
Posts: 613
Joined: Mon Oct 31, 2016 1:22 am
Location: USA

Re: A problem with outputs

Postby Robertspark » Sat Oct 13, 2018 11:08 pm

So what is the alternative?
Robertspark
 
Posts: 1892
Joined: Sat Sep 03, 2016 4:27 pm

Re: A problem with outputs

Postby Dan911 » Sun Oct 14, 2018 2:46 am

Hi Rob Terry,
I hope my post didn't come off like a know it all or programmer because I'm neither by far. I do like to read and that's something I read and remembered a while back, a simple google search will provide many links . Wait/Sleep from what I understand are basically the same and both memory hounds used for long period delays. I wouldn't expect to get good results using for a timed loop, I wasn't able to see your delay since a variable. I did experiment with this for polling loops and timer,stopwatch or tick events may be something more reliable.
Dan911
 
Posts: 613
Joined: Mon Oct 31, 2016 1:22 am
Location: USA

Re: A problem with outputs

Postby dezsoe » Sun Oct 14, 2018 6:59 am

Your macroloop runs 20 times per second. Why don't you just count it? The 50ms resolution is not fine enough?
dezsoe
 
Posts: 2049
Joined: Sun Mar 12, 2017 4:41 pm
Location: Csörög, Hungary

Re: A problem with outputs

Postby Robertspark » Sun Oct 14, 2018 8:01 am

That is fine enough for me, I just wonder why others have mentioned potential issues.

Could it be too much for the macro / macroloop to do?.... Too many macros / macro loops running exec.wait() function at the same time (too many threads waiting at the same time gives odd behaviour?)
Robertspark
 
Posts: 1892
Joined: Sat Sep 03, 2016 4:27 pm

Re: A problem with outputs

Postby cncdrive » Sun Oct 14, 2018 9:10 am

The exec.Wait function is simply a cycle of Thread.Sleep function.
How it works is that there is a code cycle with Thread.Sleep(1); and the time is measured in each cycles and when the parameter of the Wait elapsed then the cycle ends.
It was made like that because the Thread.Sleep is not very precise, so e.g. a Thread.Sleep(50); is often 50-60msec and not precisely 50msec.
If the sleep time in each cycles is 1msec and the time to break out of the loop is measured then it will be more precise, in the 50-51msec range, but I think I don't have to describe this more, it should be understandable.
One more thing is that the Wait is skipped/breaks out of the loop if the macrostop is set, if a STOP or RESET was executed, because otherwise the code execution would stuck until the Wait ends even if a STOP or RESET was requested by the user which would be annoying.

Thread.Sleep is a very basic command in Windows programming, so if it has a problem then that is a Windows issue which I have never seen.

And since macroloops are fully separate threads they will not wait for eachother, they running virtually independently, they will not wait for eachother when there is a Sleep or Wait is coded.
A Sleep puts only the particular thread (macroloop) into sleep in which the Sleep was executed.

Thread.Sleep is not a bad practise in my opinion, there are things which can't be done without it. What is a bad practise is to make the UI thread to sleep, because that freezes the UI.
But the macroloops are not in the UI thread, they are separate threads running in the background independently from the UI thread.
cncdrive
Site Admin
 
Posts: 4695
Joined: Tue Aug 12, 2014 11:17 pm

Next

Return to Ask a question from support here

Who is online

Users browsing this forum: Bing [Bot] and 3 guests