We have a development license so we can try modules that we implement. We have one that can communicate with Omron plcs. We had a first version that just could read unsigned integer values. Now we have a new one that can read/write all the supported Omron data types and some specific formats our client need. We upgraded the old module with the new. But we had the problem that the two threads appeared to be running at the same time. One with the old code one with the new. We tried everything to just have the new one working. But in the end the only solution was to unistall the Omron module, restart ignition an then install the omron module again. We thought we have solved it this way, but once yo restart Ignition with the Omron module intalled the old and new code start running at the same time again changing the value of the tags alternatively.
We thought of to possibilities:
- Whe creating the module some old classes some old stuff is being bundled. But we tried to install this module in a clean Ignition a didn’t have any problem. So we think this is not possible.
- There is a backup in the Ignition of the modules
How can I do a clean start with a development module? Should I delete some file.
It’s possible that an old version of the module file was still in the modules/ folder underneath the Ignition installation directory, which is where modules are loaded from when the gateway starts.
How can I delete this in a secure form? So I can do it everytime I install a new module.
It should be deleted for you when you uninstall a module… if that’s not working you can just delete it from the folder.
Ok. My question now is what are the diferences between upgrading a development module and unistalling and installing it again. It is needed restart ignition between unistalling a module and installing it again in order to delete it for good?
Upgrading should just be an uninstall/install behind the scenes. You don’t need to restart Ignition in between upgrading or restarting a module.
If, after upgrading/installing a new version of your module, you find evidence that classes or threads from the previous version are still hanging around, it usually means you’ve leaked a reference to the old classloader somewhere (check to make sure you’re shutting down everything properly and not leaking any references).
I tried to restart ignition because there whre old threads that I need to clear. But when restarting the web stops at RUNING…
Looking at the status get this:
[root@ignition temp]# /etc/init.d/ignition status
Ignition Gateway is running: PID:17933, Wrapper:STARTED, Java:STARTED
I think the new module is the problem, didn’t happen this before. There is a way to do a clean restart without the developed modules?
Remove them from the modules folder (by hand) and restart.
When uninstalling the module using the web the archive .modl in /ignitionPath/user-lib/modules/ is removed, but doesn’t happened the same with the .txt referring to the module in /ignitionPath/data/module-info/. I ended deleting this .txt (that only has the version of the module) by hand and the problem was solved when restarting Ignition. I don’t know if it is normal that this txt file isn’t deleted when uninstalling the module or it is something you have to code during the module development. Can anybody enlighten me with this subject?
That .txt file is only used by the Ignition installers to determine the version of modules that are installed on the system. If you delete the file, it should just rebuild itself from the list of installed modules during a restart. As far as module development, you don’t need to worry at all about this file.
When restarting Ignition I’m having the problem that my module is trying to get some resources from Ignition that doesn’t exist. This resolves in a null pointer exception. Is there a way to order modules when Ignition is started? or just I should put a sleep in the startup() of my module? Thanks.
No, there’s no order, other than if you depend on another module you’re guaranteed that it will be started before yours.
You can’t call sleep() during startup() of your module; they aren’t started asynchronously and you’ll block the startup of the rest of the gateway. What resource(s) are you trying to get that aren’t there during startup()?
The resource that throws the null pointer exception is the shared executionEngine.
That should definitely be available during setup() and startup()… are you sure that’s what’s throwing the NPE? Can you capture the exception and get the stack trace?
Here is an old pic of the exception. I can’t restart Ignition right now, because we are in production. I will do it as soon I can.
Here is the pic, something went wrong in the last post.
So this actually indicates a NullPointerException is happening in your code, not because you’re using the execution engine too early or anything.
SectorEntradaFermentacion, line 567, apparently.
This excecpiton happens when restarting Ignition, you can see the that other modules are starting when this happens. In that line we are trying to use the execution engine that we get from the context, but a null pointer exception is thrown.
Yeah, but the NPE is originating from your code. BasicExecutionEngine catches uncaught Throwables in the tasks it runs and logs them. Your code is throwing a NPE.
May be I didn’t explained it well from the start. I have this null pointer only when all the modules start at the same time, because you don’t have the resource. No problems in any other case. So I just wanted to know if it is possible to load this module the last in a restart. But it is not. So I have to find a way to avoid this behaviour, that is using a resource before having it.