New Problem

[CT63]

Just so everyone knows these drives are very,very low quality and don't meet UL or CE safety requirements. Mod bus is typically not standard. All are cheap low quality knock offs. They don't meet RF standards and lack components to even get close to UL & CE ratings. Most don't have ID stickers listing drive specs. Its not uncommon to find Chinese sellers overrate the HP/Kw specs. Bottom line.... you get what you pay for.

[Kelevra]

OK when you say it did not work . Did it not show up in teh plugin window ?? Ran but crashed UCCNC ??

I just loaded that Plugin up in UCCNC and have not seen a problem show up. Teh plugin loaded without error and teh config page is accessable.

(;-) TP

Well first it loaded up but i used an old version. Then i updated to the newer version that caused crashing, but it loaded up aswell.
Now with everything on the newest releases its not even showing up anymore.

//edit:

I uninstalled UCCNC completeley and reinstalled it. Only imported my profile and then I did a little more testing and the Versions up to 1.0004 load up fine but when i try to configure them i get an error.
The 1.0005 still doesnt show up in the list at all

[cncdrive]

There is no check for a plugin vitality, no exclusion/disabled list whatsoever.
A plugin not showing up if:

- The plugin file can't be read, not a valid file, file corruption.
and/or
- The file extension is not .dll
and/or
- The plugin file does not implement the UCCNCplugin class and/or it does not implement the 'Getproperties_event' function.
and/or
- There is something missing for the software environment to run the plugin. A prerequirement of the plugin is missing so the plugin can't load.

[Kelevra]

Thanks for the replys guys.

Matter of fact is that the 1.0005 Plugin loaded correctly the first few times i tried to load it up but it caused uccnc to crash.
I was able to setup the configuration and everything but after that the software just "stopped working" according to windows.
How does UCCNC save plugin configurations? Maybe that is the issue that it's trying to load up the plugin with old configurations causing the crash and now corrupts the file on startup?

[Kelevra]

I got a little further considering the Problem.

I've reinstalled UCCNC, but this time in a different folder. I can get the Plugin to load up and everything, my vfd is set up correctly (spindletalker works fine).
The plugin configuration works aswell and when i fire up UCCNC it tells that the connection is successful.
But sadly as soon as i hit m3 the whole software crashes without any sort of information aside from the usual "the application stopped working".
I'm going to continue tackling this issue tomorrow.

[cncdrive]

One thing I can think of could be a Cultureinfo problem.
I mean are you using English Windows?
A possible problem is if the plugin writter did not handle the cultureinfo in the plugin,
then the plugin could have problems if the culture of Windows the user running has a different culture than english and the plugin does something which requires english culture.

A good example is reading a DRO and converting it to a number.
The UCCNC has fixed english EU-us setup, and for example if the user Windows is Hungarian Hu-hu then the number formatting will be different.
An example number represented on EU-us culture 1.2345 and an example number in HU-hu culture 1,2345
The difference is that in Hungarian there is a , as the decimal separator and in the English there is a .
So, if the plugin is not setup to handle this difference and will work with reading and converting numbers that can cause a problem,
for example the result of conversion from string to number will fail with an exception or will be 0 and then if the plugin for example tries to divide with 0 will cause an exception.
Ofcourse this is just an idea about what could be wrong...

[A_Camera]

Hi Balázs,
Isn't the culture info issue fixed in 1.2031?

However... he is using 1.2029 and in that release it is still a problem.

[cncdrive]

The culture info issue what I'm mentioning here is not an UCCNC problem, but it is how the cultureinfo works in the .NET programming environment.
If you create a software thread in a .NET software like C#, VB or Visual C++ the thread you created will always have the cultureinfo defined by Windows.
Then you can change that, you can set the cultureinfo in your thread to whatever you want.
What possible issue I've mentioned is if the plugin writter has a thread in his plugin and did not set the cultureinfo in that that could cause a problem on non english windows,
because in the UCCNC the culturinfo is always EN-US, so the thread a plugin writter creates should also be set EN-US for compatibility with the UCCNC setting incompatibility problems can happen between the UCCNC and the plugin if the windows the user is running has a non english cultureinfo.

We can't fix this, because it is how the threads in .NET works.

Wat we could do is we could force set the user's thread to EN-US when the user calls UCCNC functions, but probably there would be compaints about that if we would do it,
because plugin programmers may want to use other cultureinfo threads for their own plugin tasks and then the UCCNC would always switch their threads culturinfo which I think is not a good solution.
So, it is up to the plugin writter to set the cultureinfo properly to EN-us before calling UCCNC functions and when no UCCNC functions are called then they can use other cultureinfo if required by the application.

[A_Camera]

But...

In a mail at the end of November you wrote:

I've corrected this issue now with setting the culture info for the macro loop to EN-US, will be OK in the next UCCNC release.

And for now you can overcome the issue with placing the following 2 lines to the very beginning of your macro:

Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("en-US", false);
Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US", false);

Is this now corrected or not? I understand it is not a bug per definition, but it is fixable, and normally not an issue to use Hungarian, or Swedish Windows, so strictly speaking, unless we can force Microsoft to do something about this, it is up to the software (in this case UCCNC, or the plugin) to do something about it.

Anyway, I have removed the two cultureinfo lines from my macros and don't have any crashes since 1.2030.

[cncdrive]

What you've quoted is a totally different thing and that is about the macro loop compiler where we forgot to set the cultureinfo for the macro compiler thread which was an UCCNC issue and that issue is fixable by us and was fixed.

What I'm mentioned in this thread is that plugin writers if creating their program threads in plugins which they have the freedom to do so they have to take care about setting the cultureinfo for their threads if they calling UCCNC functions from the thread.
Which may be not obvious if you don't know how threads cultureinfo works in the .NET framework is why I've mentioned it as a possible problem in the plugin which has the problem which the OP mentioned here.
So is why I asked the OP about what language windows he using and I thought to describe this as a possible problem which a developer with englsih windows may not see when developing and testing their plugins,
but can cause problems when a user running a non english windows will start using the plugin.
So, I thought to give a warning about this possible issue, so plugin developers may read this and aware of this then...