In my DesignerHook class, I have several writes to the log.
I set the logger up using the same form as for the logger in the gateway hook class.
I see all my gateway log entries.
I do not see any designer log entries.
I know the log write in initializeScriptManager is being called–if I set the Logger pointer to null, the designer crashes when I open a project, with a null pointer error. Project opens fine with valid Logger pointer.
It seems that the log entries written by the designer hook are going somewhere–but not into wrapper.log.
The designer and client have their own console where you will find the log output. Your log messages are not transmitted client/designer to gateway to be entered into the gateway’s logs.
[quote=“xasga”]It seems that the log entries written by the designer hook are going somewhere–but not into wrapper.log.[/quote]I’m kinda surprised you thought they would. They go to the diagnostics panel and console of the designer. Same for runtime in the client.
Please consider going through Inductive University to learn the basics of the Ignition Platform. It’s free.
Call to the logger in gateway hook shows up in the wrapper log.
No reason for me to think call to same logger class would show up somewhere else.
Inductive University is video only, yes?
A searchable pdf is a thousand times more useful, both in the initial learning phase and later when the memory needs to be jogged.
Online videos are useless in a plant that has no internet access. Happens frequently.
I don’t think I can help you any more, xasga. You, personally, have internet access, so can easily read the entire online manual and go through the university videos. Any install of Ignition also has an offline copy of the manual, which may be somewhat dated in some topics, but serves to jog the user’s memory. The bottom line is that you’ve jumped into the most advanced topic in the entire Ignition ecosystem, module development, without actually learning even the basics of how the platform works or how to develop ordinary projects.
You’ve made some comments suggesting you are allergic to learning Jython, and want to do everything in Java. You can’t. Jython is not really an optional skill in Ignition, even if Ignition tries to help you write the most common operations. Accept it, learn it, advance to solving problems.
Good luck.
I’m sorry to have frustrated you to this level. It is true that I jumped in at the deep end of Ignition, difficult enough in itself and made more difficult by my lack of experience in java programming.
Had I known it would be this difficult to write a module, I might have taken a different approach. But even after all this, I’m not sure that I would. We are evaluating Ignition. There are internal reasons why we need to use modules, and reasons why we need to know that modules will fill the need before spending a lot of time learning the top end of the system. True, we can do most of what we want with scripts, but that was not obvious when we started this evaluation. Once started down the module path, it made sense to keep on it, because we will need to come back to module development at some point.
I’m not allergic to Jython programming–I just left it to last. That’s where I am now, making the connection between the module and the project. I’m also new to Python, which is another reason I left it until the end. I had a lot going on with java and maven and the Ignition SDK.
I somehow missed the offline copy of the online Ignition manual. I thought I had read that there was no offline copy. I just looked through my folders and don’t see it. I’ll get a copy.
Bottom line is I hope you will bear with me, because you have helped–even when I didn’t fully adopt your suggested path for learning the system. I’m through the worst of it, not far from the end of the initial learning curve.
I’ll try to do a better job of searching the documentation before opening a new topic.
I too took the Module approach (about 2 years ago) without exploring Python approach smply because of lack of awareness of possibilities that python offers which I believe is still evolving. Module approach has a steep learning curve and despite that you are not sure if you are using the most appropriate APIs as multitude of them exists, some of them are evolved like layers of sadimentary rock over the period of 13 years of Ignitions evolution. Python would pehaps be better appraoch as you can start on a clean slate provided it can do the job at hand and its inability to hide source code and being sold as licensed module are acceptable to you. Of course in todays world of ever growing plathora of languages, its impossible to master a language first and then start development (unlike in the olden days), we need to do just-in-time learning based on what you want to achieve. Perhaps that’s what make IT industry interesting!
Pafull
One of the objectives of the evaluation is to assess the quality of the documentation. Good documentation helps the developer find his way when he comes to an apparent dead end. Dead ends are encountered when first starting out, and also when coming back to a system after being away for a while. My impression is that the documentation of the SDK is intended only as a reminder to those who are immersed in the system full time, and (perhaps) have access to information not included in the documentation. It is a good thing to have learned this up front.
That is certainly a challange for the developers of packages like Ignition to document their API’s where requirements evolve and you have to be backward compatible with previously released commercial versions. Specifications for system software are well defined first so they can be well documented (like java api’s) but its difficult for application packages to achieve the same. In fact just because Ignition has documented and exposed their API’s we have a visibility into it and are able to comment on it!. How many other SCADA packages or other application software packages expose their API’s? We use them as blackboxes. At the most they expose a few handful of API’s for integration purposes with third party software. We should commend Ignition for exposing and documenting all their API’s. The quality is relative and subjective, but I guess internally all application packages will be the same if not worse!
Prafull
My comment on the documentation was primarily with reference to its suitability to our situation. Certainly the existence of the SDK is of great value to those who need its power and are in a position to immerse themselves in it, in which case the documentation is good enough. We will likely never have a person working full time developing applications with Ignition. This is true for many of the software tools that we use. When opening a software package after being away for six months, documentation helps us to quickly wipe away the cobwebs.