Linux + Mobile + Java -- Issues & Questions

I have a Debian 6 server VM running Ignition 7.5.5 with OpenJDK 6

[quote]System Properties
Context State Running
Redundancy Mode Independent
Redundancy State Active
Version 7.5.5 (b1255)
Java Version Sun Microsystems Inc. 1.6.0_26
CPU % 12.7
Memory (used/max) 62 mb / 2.0 gb
Uptime 1 hours, 26 minutes, 21 seconds
Timezone America/Los_Angeles [GMT-8:00]
Locale en_US[/quote]

I purchased this early this year (2013) installed, did some development and left it alone.
I started development again and finished the base test project. I went to test on the mobile device (I have a mobile license) and I am getting the same (similar) error that people right now (Oct 2013) are getting with Ignition 7.6.3/Java 7 where the client is showing “Error” on the header and “Connection reset” in the body with a “Restart” Button in the middle of the page (which, just causes the same error when pushed).

The configuration page says to use Java 6 and that is what I have

[quote]Java Path
The path to the Java executable. Should be a Java 6 JRE. The default value assumes that Java is on the path.
(default: java)[/quote]

Does anybody know if the mobile module was supposed to work in 7.5.5?
Should I “upgrade” to Oracle Java 7u25?
Does mobile really work at all? Should I ask for a refund and forget mobile functionality?

I have an issue with Linux Mint (Clients) that renders the Ignition Designer useless when run on a 7.6.3 server.
I am not sure what is going on yet so I would rather not upgrade Ignition on this server till I get that worked out.

Any advise would be appreciated.

A lot of issues with the Mobile module were worked out for the 7.5.10 and 7.6.3 releases, both of which switched the mobile requirement to Java 7 from Java 6.

That being said, we’ve never claimed to support running the mobile module on Linux. In the best case people usually get it working until the first time the server is rebooted.

Regarding your issue with designers in 7.6.3: what’s the problem you’re having?

Ok I am sorry but I have to bite on this.
You are probably right, even though the System requirements page says "Full support provided for...", I am sure there is some loophole that makes that statement useless.
So in reality does this mean IA claims support for nothing? There is no compatibility matrix (and there should be), there is no requirements on the Mobile module page other than Java 7 (current version, Oct 2013).
There seems to only be this wonderful feeling of security knowing that if we can run Java it will work. An implication of "freedom of choice" and "simplicity" for plant operating systems. Until something goes wrong, which sadly has happened to me a couple times recently.
I understand that "compatibility everywhere" is difficult to accomplish but I have heard that "support" quote way too many times not to say something because you can probably say that for just about anything that has to do with Ignition.

I am not really asking for "more compatibility" from IA, I believe they are working hard already. But maybe a little more in the "tools" department. Maybe provide a few hard facts so people are a little less blind than they are now and more able to help IA provide a great product.

Forget the compatibility matrix. How about a web page (accessible from the main IA support menu) that has the following..
a) For those of us who are "testing" challenged, have a big banner..

b) You know what OS and Java version is "preferred" among the developers. Say so.
This way people can limit their choices for their own plant systems if they desire.

b) Show what platforms are tested on (You do have a test suite?)
This way people can again limit their choices for their own plant systems.

c) List what tests are run.
This way people could maybe help IA in developing/defining extra tests to fill in the blanks.

d) Provide the client and server test suites!
A user could then install a trial version, install the test suite and let it run to determine if this is going to work with my system.
Even if the tests are rough around the edges, providing them to the user base would put them in front of a lot more people/developers than IA has to spare. It could not help but get better. I am used to working on unfinished systems (or hiring an outside dev to do so) to make them more usable on my preferred OS. I am sure if IA entrusted its users with these tools and the source to add to them, they would have several installable packages for different systems in a short period of time.

Then the generic "no claimed support" statement could change to...

First of all, I’d just like to say that: you’re right, we’re not doing a good job of communicating these sorts of compatibility issues to people right now.

The Windows requirement for the mobile module only made it as far as our PDF and printed sell sheet for the mobile module, for some reason, it never made it onto the website. This is being corrected as I type.

As far as a compatibility matrix, I have to say, such a thing would be pretty boring. You’ve happened to hit upon the major one (Mobile requiring Windows + Java 7)

Really the only other compatibility issue I can think of is that the OPC-COM module requires Windows, but, that should be pretty obvious to anyone who wanted that module (I’d hope).

I also agree that thus far we’ve gotten by on an implicit assumption that people take advantage of our open-download policy and indefinitely-resettable 2-hour trial mode to test our the software on their system of choice. I suppose we should either move away from this assumption or make it explicitly stated, as you suggested.

Thanks for the feeback,