18f4620 tcpip server multiple devices on an intranet

[pingpong]

I have made a Datalogger made from 18f4620 with tcpip using enc28j60. The device works well and communicates the data collected from an instrument to the PC based application.
A single device connected in an intranet works OK.
The problem is when I want to have multiple such devices communicating readings from different instruments on either the same or multiple PC's all connected in the same intranet. Since the instruments are different, their PC programs are also different.
At present, I am keeping the port address of 1000 for all the devices and assigning different IP address to each device. I am able to connect to only one device. I want to communicate on all devices on the same intranet.
Can someone help please.

Jimmy.

[bkamen]

A lot more information would help on this...
Are you doing TCP or UDP? Are the connections persistent or created/released as needed?




Anyway, the first thing that comes to mind is this:

Did you see the number of sockets definition in the PIC tcpip stack? This limits the number of simultaneous connections the PIC will allow.

What is that number of sockets currently set at?
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[pingpong]

Thanks bkamen

I am implementing Tcp. My software is a client and the 18f is server. I connect to my 18f before starting and that connection remains on all through out.

At present the max sockets is 5. But I am going to change that to 1 tomorrow as I don't want my device to be accessible to multiple PC simultaneously.

As soon as a reading is received, my device sends the reading to the pc software.

[dorinm]

are your MAC#s different?

[pingpong]

No The Mac's are the same.

[asmallri]

[pingpong]

OK I tried with different MAC Addresses and the thing worked.

Thanks all of you.

[gpsmikey]

I forget just where I saw it, but someone suggested having one of the digital temperature sensors on your board. Not only does it provide temperature, it also has a unique serial number which can then be used to build the MAC address for your board. The end result is you don't have to customize the code for each board to define the unique MAC address, it ends up with a unique address due to the unique serial number of the sensor. Struck me at the time as a clever idea that would solve the problem easily.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[bkamen]

[andrewg]

Something useful about MAC addresses is that bit 1 in the first byte marks the address as "locally administered". You will (er, should) never see a "real" MAC address with that bit set, so if you're making up your own addresses, setting that bit should guarantee no collisions. i.e. 02:XX:XX:XX:XX:XX.

Something I also noticed the other day was that Microchip have added MAC addresses into a selection of their RTC chips (in addition to the range of EEPROMs with MAC addresses). It's becoming ever easier to get proper MAC addresses into a design.
_________________
Andrew

[gpsmikey]

Good points Ben - I am used to my local network here where I am not likely to run into a problem, but you are correct about it not being a good plan to release into the "wild" (we all know how Murphy lurks around the corners). I did hear about 10 years back (when I was taking a Cisco class) that some vendors were starting to re-use some of their old MAC addresses figuring that the original hardware they had created was very unlikely to exist any more.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[bkamen]

[bkamen]