UCR201 USB wireless pendant

[Dan911]

Most importantly what region was the UCR201 plugin set to?

[PillyWilly]

Most importantly what region was the UCR201 plugin set to?

Europe

[Dan911]

Most importantly what region was the UCR201 plugin set to?

Europe

The regional numbering format is what I thought to explore/test not language. As we all know Europe uses a comma for decimal separator and Gerry"s macros handle this to use a period and precision decimal places. The UCR201 plugin has a setting for this, Europe(comma) USA/AUS(period).

Thought could be a logical place to look for conflict.

[ger21]

As we all know Europe uses a comma for decimal separator and Gerry"s macros handle this to use a period and precision decimal places.

1) Is it required to program macros to accept a comma separator?

2) If so, how do you do it?

Afaik, none of the included macros do anything special in this area.

3) Not sure, but I didn't think all of the users with this issue are in Europe.

[cncdrive]

You have to use a . for the decimals separator and use English/USA number formats, because the macros are compiled with EN/USA culture format, this is done exactly to avoid this type of problem with the different number formats on different Windows. Because the macro is forced to use EU/USA culture format it will accept EN/USA formatted numbers and so there is no incompatibility problem with the numbers.

One thing which can be a problem though is with math calculations when the calculated number comes out in exponent format, e.g. 1.2e-6.
It happens in Windows math and then the issue is that if you converting that to a string and passing it to a g-code execution with exec.Code then the interpreter will not understand it properly, because in the RS274NGC language exponent numbers format is not supported.
The solution is to always convert the number to a fixed amount of decimal numbers or to check the string for the e character and if it has it then convert the number.
It has to be done in the macros, because Windows may output exponent format, it happens with very small and very large numbers when there would be lots of 0s otherwise, like 0.00000012.
So, this might be the root of the problem, but ofcourse this is just an idea from me for now, because we did not see the issue yet, so it is just a guess.

[cncdrive]

The region setting in the UCR201 is because in the USA and in Europe different frequencies are defined for the free radio channel which can be legally used for radio transmitting.
It is 868 and 434MHz. And what is the free radio channel frequency in Europe is the taxi radio channel in the USA, so the user has to select the proper region to not interfere with the taxis, to comply the local radio rules.
So, the region setting is only for this purpose, the pendant selects the proper radio frequency for the selected region and communicating on that frequency.

We not using Wifi, but the free radio channel instead, because wifi is often flooded/overloaded at places and wifi is 2.4GHz and 5GHz which is a much higher frequency than the free radio channel 868 and 433MHz,
and as the frequency gets higher the transmit range goes lower when transmitting with the same power. And ofcourse the transmittable power is limited by standard.

[ger21]

The solution is to always convert the number to a fixed amount of decimal numbers or to check the string for the e character and if it has it then convert the number.
It has to be done in the macros, because Windows may output exponent format, it happens with very small and very large numbers when there would be lots of 0s otherwise, like 0.00000012.
So, this might be the root of the problem, but ofcourse this is just an idea from me for now, because we did not see the issue yet, so it is just a guess.

My macros already do this, as this came up a year ago, and I fixed them all to avoid this issue.

[cncdrive]

Ok Gerry, then it will be something else which we seem to can't figure out. At least not so far.

[Dan911]

Hi Ger,

As Balaz explained here the same as he did in an older thread I understood any Cultural Info in a macro is handled within UCCNC (EN/USA), NOT the same for plugin though and needs to be addressed.
I know nothing of this issue other than what I read in this thread and only facts that seems clear is pendent/plugin works with no issues and screenset/macros been working flawless, put together there's a conflict. I posted what seemed to be obvious to me.

The explanation of the regions setting in UCR201 plugin sorta blows this guessing theory out the window....

One thing which can be a problem though is with math calculations when the calculated number comes out in exponent format, e.g. 1.2e-6.

I see Ger's macro limits to 2 decimal places which I would think should avoid this error, also if only happening when plugin is enabled than something is changing it's calculations?

Interested in seeing end result cause.

[cncdrive]

Hi Dan,

The Cultureinfo thing is for program threads. There can be 2 cases, we set it to EN/US or we forget to set it and then Windows uses the cultureinfo of that particular Windows installation.
When a macro thread is created then we set the cultureinfo to EN/US, so the macro always has the EN/US cultureinfo.

In plugins in the events/calls we also set the cultureinfo to EN/US when the thread is created and so the plugin writter does not have to set the cultureinfo.
I mean this is the plan how it should go, but a few times we forgot to set the cultureinfo for some events/calls and so then an issue could happen in the plugin if the programmer of the plugin did not take care to set the cultureinfo for that event for his code, if he coded things in the call which are cultureinfo dependent.
And in plugins the plugin writter can create their own threads which are independent of the UCCNC main code, so we can't set the cultureinfo for those externally created threads, for those the programmer of the plugin has to set the cultureinfo properly if it is required for his code. (The best if it is just set)

I have an idea though (and this question is to PillyWilly, because he can reproduce this issue), it is not about the cultureinfo, but to debug to see it closer where the problem lies.
My idea is that I will make a test UCCNC.exe in which I will code some Console writelines directly at the exec.Code calls to see what exactly texts does the Exec receives for execution from the machine.
Then PillyWilly could simply redirect that to the Console debugger to see the texts. And when the problem happens then he can upload a printscreen to let me see.
I would especially like to see what commands are sent to the executer, what commands, what coordinates etc. to understand the issue better.
So, the question to PillyWilly is if you will install this exe if I make one and if he will print some results for me? I mean I will only make this if he is willing to test it, because otherwise it would be useless to make anything like that, because the issue is unreproducable at us.