5500PC/Ethernet

I have a network with 5500PC which has worked flawlessly since installation 5 or 6 years ago. At various times over the years, I've used the 5500PC connected to a Lantronix 8-port terminal server and been able to program, monitor and control the network both locally and remotely in this manner.

In the last 6 months or so, I've upgraded Toolkit and things have been working fine locally (via RS232 connection to the 5500PC). I've not needed to use the ethernet interface.

Today I reconnected the ethernet because my new computer doesn't have a serial port (and my office is at the other end of the house). I can't get it to work.

I've configured the port thus:

Port 6 : Username: Physical Port 6 (Idle)

Char Size/Stop Bits: 8/1 Input Speed: 9600
Flow Ctrl: Cts/Rts Output Speed: 9600
Parity: None Modem Control: None

Access: Remote Local Switch: None
Backward: None Port Name: Port_6
Break Ctrl: Local Session Limit: 4
Forward: None Terminal Type: Soft()


In Toolkit, when I configure the port (correct IP address, which I can ping and telnet to the port fine) and try to open the network, there is some network activity (as observed by sniffing the ethernet segment), some 30 odd seconds passes, then "Error 22918" dialog box pops up and says "PCI Failed to reset. Unable to open the Network."

In the Java window, I see this:
20101029-133015 824 //SHAW/1 a4eaa710-c51b-102d934e-8e3cb972be44 unknown response: ~~~ ***


Given this used to work and now doesn't, has there been some additional code added to check the interface is *really* a CNI and not some other ethernet->RS232 converter? Can I work around this?

I'm currently running Toolkit 1.11.2

 

Did you set the software up in the same way ?

I notice that unless the serial port emulation is correct there will be a number of phantom issues.

 

Well, the old version of toolkit I had been using (from memory) only had a single option for the "connected via network" option - and that was to enter the IP address and port. The 8-port server hasn't changed, but toolkit now has several quite specific options rather than two generic (Serial/Network) options.

"serial port emulation" isn't happening (or rather, shouldn't be!). If toolkit is connecting to a network socket, there's no serial emulation to do. At the other end, it's a physical serial port so it's not emulating the port - it's connecting to it. I have this same terminal server doing a multitude of other jobs (weather, security, real-time lightning and more) - and they all behave perfectly (and have done for years).

It's possible it's a simple setting that needs changed, and hopefully someone here can point it out. I can do a tcpdump of the (raw ethernet) data if that'll help anyone.

 

Idiot!

Ever wish you could go back an hour or two and undo the dumb things you just said/did?

I got to thinking, and thought I had more than 5 things plugged into that device (which would have left port 6 as the next free port).

Of course, when I went and checked, the cable was actually plugged into port 8, not 6. As soon as I changed toolkit to connect to port 2008 instead of 2006, it sprang into life instantly!

 

We've all been there. Nothing to be ashamed about.

 

The emulation takes place via a SOFT COUPLING on the PC called Redirector. If this installation of Redirector does not yet know which method you are intending to use (working from default) then it may not answer your needs as expected.

AFAIK I had some issues trying to get Toolkit directly coupled to 5500CN. I prefer to use a phantom serial port on my PC which is redirected by the tool called SERIAL PORT REDIRECTOR.

Can I also recommend that most likely you could obtain a newer firmware for the serial port box (firmware AND .cob file) and upload those to your current hardware. (never do that on a Tecom Alarm as the Tecom Lantronix variant uses special codes and is tested to work)

With the latest software, the latest firmware and the latest Lantronix help file I was able to validate all of my issues and remove them one by one.

If you could install a loopback module on the far end (instead of the 5550PC) then it would serve to validate any issues arising from the 5500PC itself.