Local App and Classic connections. Classic goes away and comes back ETC

[Westbranch]

Tom, looks like you, and I, will have to stay with an 'old' version of AIR if it can be located...

http://en.wikipedia.org/wiki/Adobe_Integrated_Runtime
It also originally supported Linux, but that support was discontinued.


ADD : V 2.6 is the last one

http://helpx.adobe.com/air/kb/archived-air-sdk-version.html

[Resthome]

Ok Andrew thinks he knows what it is and it has to do with the way he requests Live data from the PC's hard drive or something. He is working on it and we will keep everyone posted.

Ryan

After looking at WireShark network data  the Classic is 196.168.1.100 (Static) my computer is 196.168.1.110 (DHCP). DHCP begins at 196.168.1.110.

A screen shot of WireShark network trace of the Classic and Local App connection drops while in the Data tab is attached. Filtering on only the TCP data packets it appears that the Modbus Read Multiple Register commands usually have a query packet from the APP and then a response packet from the Classic. Before the APP sends a Finish Flag there was a Query from the APP but no response from the Classic. So for some reason the Classic is not sending a response. The APP then sends a ACK, FIN (Finish) and disconnects and throws the error message. Not sure if it resyncs without dismissing the error message and clicking the View button. I think it does as the same disconnect happens with the AutoRestart at midnight set to reboot the Classic and the data continues to be acquired while the Error message is still displayed.

[boB]

After looking at WireShark network data  the Classic is 196.168.1.100 (Static) my computer is 196.168.1.110 (DHCP). DHCP begins at 196.168.1.110.

A screen shot of WireShark network trace of the Classic and Local App connection drops while in the Data tab is attached. Filtering on only the TCP data packets it appears that the Modbus Read Multiple Register commands usually have a query packet from the APP and then a response packet from the Classic. Before the APP sends a Finish Flag there was a Query from the APP but no response from the Classic. So for some reason the Classic is not sending a response. The APP then sends a ACK, FIN (Finish) and disconnects and throws the error message. Not sure if it resyncs without dismissing the error message and clicking the View button. I think it does as the same disconnect happens with the AutoRestart at midnight set to reboot the Classic and the data continues to be acquired while the Error message is still displayed.

Good detective work, John.

We used wireshark too.  What a great program !

I'll clue Andrew into your findings.

boB

[atop8918]

Hi, everybody,

The dropping in the data tab seems to be an Adobe Air performance issue and kudos to John's excellent wireshark sleuthing. It can't handle the file and networking simultaneously. Usually a missing response packet from the Classic is not grounds for closing the connection unless AIR gets hung up waiting for the disk. This is one of many reasons I'm changing our application framework to leverage some more robust technologies and we'll be dropping AIR like it drops network connections.

Ubuntu and other fellow Linux flavored users, please take note of my disclaimer on the bottom of the app download page:

http://mymidnite.com/

Adobe dropped Linux support at version 2.6 and, regrettably, we have had to follow suit. The app up to version 2.6 is supported for Linux, but any newer revs are use-at-your-own-risk. I've had some luck running the app on Ubuntu 12.10 under wine, but as a small company we don't have the resources to support an unsupported platform. I'm very bummed at Adobe's decision as Linux support was one of the main criteria for using AIR in the first place.

Thanks!
-Andrew

[Resthome]

Even the Photoshop suites rarely get bug fixes, just new versions that you have to pay for. And the Elements products are all developed in India and only the Product Manager is in San Jose.

Will be glad to see the new Web Server.

[Westbranch]

Hi, everybody,
I'm changing our application framework to leverage some more robust technologies and we'll be dropping AIR like it drops network connections.
-Andrew

Andrew any comments about the "more robust technologies" you will use?

Eric

[Vern Faulkner]

Andrew any comments about the "more robust technologies" you will use?

Eric

Probably involves words I can't publish or say on air.

[Westbranch]

Ahw, pushaw....

[atop8918]

We're going to start doing a web-based interface directly on our products like almost everybody else does, although compared to my current solution, a couple of rocks banged together could be considered "robust".

[TomW]

We're going to start doing a web-based interface directly on our products like almost everybody else does, although compared to my current solution, a couple of rocks banged together could be considered "robust".

Good the hear!

Every project starts someplace. At least a couple rocks are durable! And change keeps you from getting bored.

Waiting patiently. Well kinda.

Tom

[dgd]

We're going to start doing a web-based interface directly on our products like almost everybody else does, ...

Thats the way to go       there are plenty of examples of web
servers for embedded processors but i have noted some recent chinese mppt controllers advertising a second  ARM cpu just
to provide 'web based user interface'. The LPC236 series ARM processor in the Classic should have the grunt and memory
available (unless boB has used it all in mppting)
Can that MNGP processor and memory be leveraged for web interface use? Is it also an LPC236 type?
I had thought it would be nice to have a web cpu/ram/storage (SD card) module that replaced the MNGP/lite panel if the
Classic resources were just too meagre
But maybe this is going too far for a simple web face just like Cisco Linksys WRT45G

dgd