Firmware Upgrading

[juwi_uk]

I did something today that gave me a scare for a few moments.

Upgrading to the latest 5.199 Ult firmware.

I setup programming cabling and started the firmware upgrade as usual in Comfigurator and it got to 5% upload and failed.  Tried again and it got to 10% and failed. Oh no I started to think.

Fortunately I wasnt totally asleep and noticed I had my ComfortClient open and connected.  

Shut that down and then the upgrdae went through fine as normal.

Now whilst I\'d had the Client Open here it could have been Wizcomfort or anything else for that matter.

Shouldnt Comfigurator check for any current open sessions on the UCM before it starts to upload and if found politely request that they be closed first?

Regards

Julian

 

 

[ident]

You are using UCM/Ethernet I presume. I dont think Comfigurator knows if there is another open session Does the Comfort client know about other open sessions on the UCM/Ethernet?

[Ingo]

That might be more difficult than it seems. I think it needs to be a function of the Tibbo module to restrict any new TCP connection attempts when there is one already established.


I found the following explaining exactly why the upgrade failed. Sorry Julian, looks like we cannot check for existing connections.

[size=2][size=2][size=2]

[size=2][size=2][size=2][size=2]TCP reconnects. [/size][size=2]When the data TCP connection between the DS and the network host is already established and another network host (with a different IP-address) [/size][size=2]attempts to connect to the data port of the DS this connection attempt is rejected (because the DS only allows for a single data connection at a time). However, if the second connection is attempted from the same IP-address (as the IP-address with which existing TCP connection is established) then the DS will \"switchover\" to this new connection. This means that the DS will forget the first connection and accept the second one. Such behavior is implemented to avoid DS stalling by hanged connection. Consider this scenario: the application on the network host has a TCP connection to the DS in progress. Suddenly, the application crashes- connection is left hanging because it wasn't properly terminated. When the application is relaunched it attempts to establish a TCP connection with the DS again. If the reconnect feature wasn't implemented the DS would have considered this to be an attempt to establish a second concurrent data connection and would have rejected it. Owing to reconnect feature the DS will recognise that this new connection attempt has originated from the same IP-address and switch over to this new connection. The downside of this arrangement is that two (or more) applications communicating with the DS from the same host can interfere with each other's connections- each new connection attempt will take over the existing one.[/size][/size][/size]

[/size][/size][/size][/size][size=2] 

[/size]
Ingo

[juwi_uk]

Oh, that\'s a shame.

Hey Chiu, what about he idea of bringing out a new Ethernet daughterboard based one one of the later Tibbo modules.  I see for example the EM1000 has 4 serial lines and support for WI-FI etc, not to mention bigger buffers and 100BaseT support.

The EM100 is feeling a bit dated now and some of the new Tibbo modules open up some great connectivity options.

Julian

 

 

[juwi_uk]

Incidentally I was using DS Manager.  It seems to know whether there is already a connection in progress.

I\'ve attached an image which shows the 2 scenarios; one where nothing is connected and secondly when I have the ComfortClient open and connected to the UCM.

Must then be possible to poll this info somehow.

I\'m presuming it\'s a UDP session or something that determines this?

Julian

[slychiu]

I dont know how they detemine the connection

We will be looking at some of the newer tibbo modules