Ethernet comms module

[sggaunt]

I/We have a project to design a hardware device that sends data to a PC application via Ethernet.

This isn't anything I have done before so any pointers about the best way to tackle it would be appreciated.

The project requires an interface with Ethernet to extract the data. [this would be in the form of a simple protocol perhaps 10 or so bytes in length].

The customers applications are all written in VB (.net)

There seem to be several ways of tackling this but not much in the way of examples.

Does any one know of any Delphi modules/components that would be suitable.
I have D7 Enterprise with the Indy components installed perhaps there is something in here?

We need to encapsulate this in a dll so that the VB applications can access the data. Any special problems here?


Steve: Delphi a feersum engin indeed.

 

[buho]

I assume you are talking about Ethernet as in a NIC (network card).

Are the electrical emgineers going to use TCP/IP in their dongle (what I doubt *very* much) or raw Ethernet protocol?

If they are going to use Ethernet protocol you need a *driver* to talk with the NIC. Without a full fledged high-level protocol you'll not be able to get the data at application level. And the only protocol you are going to get a component for is TCP/IP.

There are many ways to write the driver, from the low level NDIS to the middle level LSP... but all are horrible difficult. Furthermore, many of them are not suited to be programmed with Delphi. May be none of them are well suited to.

Drop from

http://www.pcausa.com/

and read everything there and everything in the links. Better if you are fluent in C.

If you manage to talk with the NIC from a Delphi DLL, no problem defining it to be VB compatible; you'll have some issues passing strings, but they can be solved. You can make a COM server too (in-proc component or automatable EXE), VB have a good COM management and working with COM in Delphi is easy.

HTH.
buho (A).

 

[sggaunt]

Thanks Buho, but not what I wnat to hear!!

Are the electrical engineers going to use TCP/IP in their dongle (what I doubt *very* much) or raw Ethernet protocol?

My colleague (Doing the hardware for this) is looking at 'PIC' Micro-controllers with Ethernet capability.
What the customer wants to do is 'Plug' his Racks straight into existing LAN's (so its cheap to implement he says).
Head's together time.




Steve: Delphi a feersum engin indeed.

 

[sggaunt]

I'm told that the 'PIC' Chip we are looking at using, does implement a full TCP/IP stack, but we are checking...

Steve: Delphi a feersum engin indeed.

 

[buho]

If the dongle talks a TCP/IP (or UDP) dialect understandable by Win you have no problems.

The complicated part in any hardware interconnection project is surfacing the data to the application level (what involves drivers and the like). After you have the data at your disposal nearly nothing is impossible.

If you are going to design the data protocol and implant it in ROM, take in account some details:

- TCP/IP is "delivery assured" (if the network does not crash for true) but UDP is not.

- Design from the ground up an informative protocol (add packet numbering and sizing and CRCs at data level). In normal operation you are not going to need packet numbering and CRCs, but they can be invaluable for debug. Having the size of any packet expressed in the packets is a blessing in most situations (or a dire need).

- Think in having a "sender" field in the packets. Not of any use if you have only one dongle transmitting, but useful for debugging if you add another in the future.

- Think about implementing an "I'm closing" packet in the dongle, to know where it is closing in an orderly fashion.

Start every packet with a header like:

TMyHeader = packed record
Size : cardinal; // First field - packet size
Number : cardinal; // Packet number
Sender : cardinal // Sender address (IP?)
end;

End the packet with a CRC, or add the CRC in a header field (having a CRC in the header makes programing a little convoluted, but easy anyway, your choice).

As an option, you can add a PacketType field in the header if you have a lot of different packets. It is very very useful if you are going to burst out packets with different internal structure. In this way, the receiving app can check the packet type and move the raw data to a structured record (or point a typed pointer to the raw data, or use a variant record to receive all the packet buffer if all the record types have a well defined size).

- Think about a two-way communication. Interrogating the dongle about his internal parameters/configuration/state can be a very useful tool in the field. The ability to reprograming some parameters in the dongle can be a big help too.

- Think about the spatial distribution of the hardware. If the dongle is going to be near the ceiling, or two hundred meters far from your testing machine or in an area closed at some hours (say: at nigth), having the power to reset it remotelly can save you a lot of blues (believe me, I know it very well).

- Put LEDs in the dongle. If you have it near, having visual clues about the dongle state can save you a lot of anguish. Give it some LEDs saying "I'm transmitting", "I'm receiving", "I'm idle", "I'm reseting". "I'm powered" can help too .

HTH.
buho (A).

 

[sggaunt]

Its been a while but I now have some more info on this.
You will be able to tell from this that we have a lot to learn here.

We have obtained a Demo Module from Microchip.
The Module has a small Ethernet connector and the PIC can be programmed with the demo code supplied by Microchip.
We can then connect this into out LAN and assign it a TCP/IP Address within our Network range.
Its then possible to access the 'Web page' generated by the module by entering the address into Internet Explorer on any computer on our LAN.
Its possible to interact with the hardware on the module using the page.

What our customer wants is to be able to access the hardware using, Process control type software written in VB. We/I will attempt to implement a DLL in Delphi that can strip out the Low level info from the ICP/IP or UDP.

It seems that since finding out about the Microchip demo he thinks that also being able to access his hardware via a web page is a good idea, so maybe TCP/IP and not UDP.


Am I correct that for simple data transfer UDP is OK?
but make little difference as far as the Delphi code is concerned.

That's assuming that my college can work out how it gets in there, and how the 'C' code interprets incoming data.
As I say we have all the Microchip demo code so that should be possible.

So going back to the original question, It would seem that the Delphi application will be looking at a fully implemented ICP/IP Data or UDP. Are there any components will allow me to get at the data?
Indy has TCP and UDP components are these the correct things to use?






Steve [The sane]: Delphi a feersum engin indeed.

 

[whosrdaddy]

Steve,

it depends hwo you want to implement the communication: synchronous or asynchronous.

for sync (blocking) developping use Indy, for async (non-blocking) go ICS.

choosing between TCP and UDP depends on the type of application, if you need multicast or real time mulitmedia, use UDP (bear in mind that with UDP you are never certain your packet will arrive at its destination) if you are going to design a custom protocol, use TCP, it has the control layer built-in.

I prefer Indy (sync developping). Async implementation is a lot more difficult and involves using a state machine...

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[Kartman9]

Would it not be easier to write the code in VB rather than have something that will call Windows DLL's in Delphi add a layer then have VB call it?

The choice between UDP and TCP depends on the intended application. Whilst UDP has no connection state and no guaranteed delivery, if the comms is via a local network, packet loss should be minimal if any. It's like having a RS232 connection - if its plugged in you get data. Also if your data is 'live' data as in temperature from a temperature sensor, if you loose the data - what is the net impact? As long as you don't loose too much data. TCP (TCP/IP is used to describe the whole set of protocols including UDP as UDP uses IP to transfer packets) is connection oriented - you have to go through a connection sequence and the protocol has retries, etc. sometimes this causes problems if you have poor connections - packets get backed up etc. UDP just looses the packets.

I did a lot of this stuff years ago - back in the days of Delphi 1 & 2. I called the Windows API directly. Not too difficult. I think the AsyncPro package has some socket objects although I've not used them.

I would suggest you write little apps to talk between computers to get a feel for UDP and TCP comms.

If you wanted a fast pre-packaged solution - use serial->ethernet converter boxes like the ADAM4570 and everything looks like serial comms on your PC side and on the otherside. There's also other products that do similar things.

 

[sggaunt]

Its not an option to use VB.
and Pre-packaged solutions are out as well. We did suggest that RS232/485 comms has worked well for years, We even do a Modbus version of our core product that can talk to Devicenet and Profibus via a (bought in) protocol converter, but the customer wants an ethernet connector on his board, and no other hardware, just a PC.

Anyway we have a Microchip demo board set up and connected to our network It can do both but is setup as ICP/IP at present, I should be able to at least 'hear' it talking?

I've been looking at some Indy demos (Indy9Demos)
In particular IdTCPDemo has Client and Server sections.

There are no comments on usage! in these modules.

Should it be possible to acces our demo board with one of these?
I know the IP Address assigned to the Module and the Port number of our Proxy Server.

Missing a big chuck of knowledge here I think?




Steve [The sane]: Delphi a feersum engin indeed.