New Problem

[A_Camera]

Yes, shortly after the editing time was over I realized that this is going to be the answer. The question now is, are those two lines what's needed to fix it? Just like in the macros, at the beginning of the code, or something else is needed?

[cncdrive]

Yes, those are the 2 lines which can be used to set the thread cultureinfo to EN-us and that fixes the problem.
But if you create for example 10 different threads in your plugin from different functions then you have to take care to write those 2 lines into all of the functions which are used to create the plugin threads before you start calling UCCNC functions from the threads.
Ofcourse there are other ways also to take care of this if you know what functions you calling and what conversion problems can different cultureinfos incompatibility can cause, then you could handle them one by one if you want without switching cultureinfo.
For example if you read strings from DROs and you convert them to numbers yourself then you could write your own conversion routine which takes care of all possible cultureinfos.
Ofcourse this was just an example, just to let you see what I ment, because in practice this would be not too easy, because number representation can differ by culture and there are lots of possible representations.
And definately adding those 2 lines is the easiest way to deal with the problem, because then your plugin thread and the UCCNC will use the same cultureinfo, so they will be sure compatible.
And in case your plugin still needs to use other cultureinfos for any reason then you can switch the cultureinfo of your thread back to other cultures the same way, using the same code lines, but with other cultureinfo strings in the parameter.

[Kelevra]

I've gotten the Plugin to work now after i switched the language of my OS to english.
Basically it looks like you guys were right on track with the guess regarding the cultureinfo.
All the issues went away magically and i'm currently running 1.2029 with the Plugin version 1.0006.
Thanks to you guys and the guys on CNC Zone for helping me out on this.

regards
Patrick

[Dan911]

While I cannot see teh sorce code I did investigate a bit further. When the Plugin starts up it DOES hog a huge amount of CPU Resources and on some systems that may cause a crash.

Just a thought, (;-) TP

Hi TP, I did see when plugin loaded my CPU usage went up 20%, due to UCCNC software security I'm unable to use a profiler to easily see what's using theses resources. I did test a stripped down version of the plugin with basically just the macro running in the plugin 25hz plugin loop and there was no difference. I THINK its safe to assume that if using the 25hz loop you are going to see an increase in CPU usage. Oddly though when using as a macro loop the CPU usage was lower. Of course there's other programing directions to go and not use the 25hz plugin loop but my CPU running at 20-25% don't seem like a issue to me.

Thank you Balázs for your tips. Like you suspected Kelevra is using a German version windows and I created a Thread for calculations without addressing the cultureinfo class. I wish I was able to get inside your head for a few minuets than there would be 1 version of this plugin and I would of moved on to another fun project a month ago.

Thanks again,
Dan

[A_Camera]

Yes, those are the 2 lines which can be used to set the thread cultureinfo to EN-us and that fixes the problem.
But if you create for example 10 different threads in your plugin from different functions then you have to take care to write those 2 lines into all of the functions which are used to create the plugin threads before you start calling UCCNC functions from the threads.
Ofcourse there are other ways also to take care of this if you know what functions you calling and what conversion problems can different cultureinfos incompatibility can cause, then you could handle them one by one if you want without switching cultureinfo.
For example if you read strings from DROs and you convert them to numbers yourself then you could write your own conversion routine which takes care of all possible cultureinfos.
Ofcourse this was just an example, just to let you see what I ment, because in practice this would be not too easy, because number representation can differ by culture and there are lots of possible representations.
And definately adding those 2 lines is the easiest way to deal with the problem, because then your plugin thread and the UCCNC will use the same cultureinfo, so they will be sure compatible.
And in case your plugin still needs to use other cultureinfos for any reason then you can switch the cultureinfo of your thread back to other cultures the same way, using the same code lines, but with other cultureinfo strings in the parameter.

I think this is extremely important for every plugin writer to know about. After all, majority of the world is not using English Windows. Adding those two lines can definitely not hurt even in case they are not needed. Maybe after an update of some sort suddenly they are necessary.

[A_Camera]

I've gotten the Plugin to work now after i switched the language of my OS to english.
Basically it looks like you guys were right on track with the guess regarding the cultureinfo.
All the issues went away magically and i'm currently running 1.2029 with the Plugin version 1.0006.
Thanks to you guys and the guys on CNC Zone for helping me out on this.

regards
Patrick

Good to know that it was so easy to fix it, but hopefully Dan will add those lines so others won't experience the same issue and you can switch back to use German.

[Kelevra]

I've gotten the Plugin to work now after i switched the language of my OS to english.
Basically it looks like you guys were right on track with the guess regarding the cultureinfo.
All the issues went away magically and i'm currently running 1.2029 with the Plugin version 1.0006.
Thanks to you guys and the guys on CNC Zone for helping me out on this.

regards
Patrick

Good to know that it was so easy to fix it, but hopefully Dan will add those lines so others won't experience the same issue and you can switch back to use German.

To be honest its not that big of a deal using an english OS. Most people are mulilangual these days anyway.
Nevertheless im happy that it all worked out.
Now i'm going to tackle the whole modbus/arduino thing that i saw some people alread working on because i'd love to have some analog inputs.

regards
Patrick

[cncdrive]

Guys, it's great to hear I could help you figuring out the problem and thank you Dan for your work on the plugin.

Hi TP, I did see when plugin loaded my CPU usage went up 20%, due to UCCNC software security I'm unable to use a profiler to easily see what's using theses resources. I did test a stripped down version of the plugin with basically just the macro running in the plugin 25hz plugin loop and there was no difference. I THINK its safe to assume that if using the 25hz loop you are going to see an increase in CPU usage. Oddly though when using as a macro loop the CPU usage was lower. Of course there's other programing directions to go and not use the 25hz plugin loop but my CPU running at 20-25% don't seem like a issue to me.

Yes, the UCCNC is obfuscated and also it uses mixed .NET and native codes, so you can't debug it with profilers.

Well, 20-25% CPU usage by the plugin sounds a lot.
Maybe you doing some GUI operations in a loop on your plugin form?
Windows GUI operations can easily become a CPU hog, redrawing labels, picturebox images etc. can use up lots of CPU time, this is one reason we went OpenGL with the UCCNC GUI.
If you doing these kind of things then try to remove parts of codes to see which ones causing the high CPU usage and if you find that code part then try to optimise it, e.g. with lower refresh rate where possible.

[Dan911]

I was able to narrow down what's causing the excessive CPU usage. I'm getting, setting and checking 6 different variables within the loop, once removed CPU usage dropped to 1%.

Big thanks goes to Vmax589 who pointed this out and was a huge part/help from the start.

Dan

[Dan911]

Hello all,

I'm hoping someone could help shed some light on this excessive CPU usage problem within the plugin. I previously posted when removing variables from loop the CPU usage dropped from 25% to 0%. The variables was used for conditions when to write to the VFD and by removing just flooded writing string arrays to VFD. This helped me trouble shoot that the actual problem is the Serial Port don't like to sit idle.
As long as data is being exchanged between VFD and plugin the CPU usage hovers around 0%, but once the reading and writing stops the CPU usage sky rockets! There are obvious solutions to this but with a better understanding why this is happening would really help.

Any input will be appreciated.

Thanks,
Dan