Probing not working in 1.2022 with UC100

[cncdrive]

Hi Eric,

Thank you for your help with this.

This makes perfect sense, because the Wait function was changed when going from 1.2021 to 1.2022 and after checking it I see what the problem is.
Why it was changed is because originally the Thread was slept for the set amount of time in a single Sleep call with the time interval set in the parameter of the wait,
but the stop and reset could not terminate the sleep, so we changed that in a way that it now waits in a loop with 1msec each sleep for the times of the parameter,
so for example Wait(100) is a for loop with 100 times of 1msec sleeps.
The issue with that is the Thread.Sleep does not guaranteed to be very precise in all circumstances, especially not for very low values like 1msec, especially not precise with slower PCs,
so I don't know what we were thinking of when we changed the wait to how it is now.
What I will do now is I will rework the wait function, the idea is that I will still wait in a loop, but will measure the expired time also and will skip the loop if the time expires,
this should be precise and also skipping out of the function on Stop will be still possible.
I will try to make this development over the weekend and will upload a new test version as soon as I will finish...

[eabrust]

Hi Eric,

Thank you for your help with this.

This makes perfect sense, because the Wait function was changed when going from 1.2021 to 1.2022 and after checking it I see what the problem is.
Why it was changed is because originally the Thread was slept for the set amount of time in a single Sleep call with the time interval set in the parameter of the wait,
but the stop and reset could not terminate the sleep, so we changed that in a way that it now waits in a loop with 1msec each sleep for the times of the parameter,
so for example Wait(100) is a for loop with 100 times of 1msec sleeps.
The issue with that is the Thread.Sleep does not guaranteed to be very precise in all circumstances, especially not for very low values like 1msec, especially not precise with slower PCs,
so I don't know what we were thinking of when we changed the wait to how it is now.
What I will do now is I will rework the wait function, the idea is that I will still wait in a loop, but will measure the expired time also and will skip the loop if the time expires,
this should be precise and also skipping out of the function on Stop will be still possible.
I will try to make this development over the weekend and will upload a new test version as soon as I will finish...

Hi Balazs,

Glad to hear this was an easy find!

I'm also sad to hear the PC I deployed in the shop as my new controller is already 'slow' I thought it was a great step up from an ancient P4... -doh- In practice, it performs great, it also just seems to have a knack for finding these bugs...

regards,
Eric

[cncdrive]

I'm also sad to hear the PC I deployed in the shop as my new controller is already 'slow' I thought it was a great step up from an ancient P4... -doh- In practice, it performs great, it also just seems to have a knack for finding these bugs...

Well, it executes the Thread.Sleep slow, so it is probably not a very fast computer,
however it is not sure it is generally slow, because Windows handles the sleep different on different computer architectures
and on single and multi core CPUs etc. so it is absolutely not sure the computer is slow.
What I originally wanted to say is that if a computer is slow then it is very likely that this bug will show up.