Lost on LAN line

I have a need to use the ethernet port for I/O connection to the outside world. I have no need to gain access to any networks, I just want to be able to send and recieve data to a PC. Think of this like a parallel port.

I have been reading all the posts in this section, but must admit I know nothing about ethernet connections. Is this something that can be done with 1 of the many chips referred to through this section of the forum?

I am sorry to sound vague, but I really don't even know what to ask to get started asking questions. I see there are serial to ethernet adaptors, can I assume this would act like a rs232 to USB adaptor? In other words the PC would think its talking to the network card, and the PIC would think its talking to the serial port? I don't want to send AT commands.

My device would be a slave, all comms would start from the PC. For instance the PC would send a read data command, and the PiC would respond with the packet of data. OR, the PC sends data, and the PIC grabs it and does what it needs to with it.

Here is a link to what I want to acheive:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Etherlab

Thanks for reading this LOONNg post.

I think the easiest way to acheive this is to use the Charron module, or some alike. They are plug and play, and you control them with simple Serial command. You can even use Hyperterminal for that
http://www.hw-group.com/products/charon1/index_en.html
they also provide some code example for various PC language.

Sure enough there's more than charron one on the market, but I don't know... really need to refresh my stock for that one day...before
http://free.timeanddate.com/countdow...05-21T18:00:00http://free.timeanddate.com/countdow...05-21T18:00:00
Time goes by too fast :D

HI;

I recomend you TIbbo Module. Its very easy to use.
This;
http://tibbo.com/products/modules/minimo/em500.html

Or this;
http://tibbo.com/products/modules/em1000.html

It dependes how much I/O-RS232 Ports do you intend to use

Oh thanks Steve. More to say now, the PC side will be handled by linux/EMC2. On the PIC side, I need to get faster then 115K - I think. Really best case is a parallel output. So I guess I don't actually want the serial->net, I guess I want PIC->net. So I need the preprogrammed interface chip and not the whole converter. Assuming there is such an animal.

LOL on the countdown

It's not really clear what you want to do but the WIZ110SR or WIZ812MJ from WizNet are some of the lowest price adapters around.

OTOH, if you are planning to use an ethernet capable PIC, you can find some code here for that.

I use Lantronix XPorts and MatchPort AR parts. They aren't too easy to setup from the "serial side" (it is doable, however), and setup from the "network side" is a breeze. They work well and the nice thing about an XPort is the small size. Just supply 3.3V and a serial connection and you are good to go. They are about $50 each in small quantities.

Ok, let me give this another go. In the beginning there was the ISA bus. It was quite simple to make a card to plug into it and have I/O using an 8255 or simular. Then that was replaced with the PCI bus. Not near as useful from a homebrew interface card. But we still had the parallel port. If used in EPP mode, quite high speed could be had using a pretty simple homebrew card. I have a card now that gives me 64 I/O lines, all through the pport. This is all needed for my current CNC control.

But the parallel port is going away also, so we are left with few choices if we want to use our computers for anything other then surfing the net or playing games. we have:

USB - Great interface but not realtime. Service could be as long as 10mSec delay. No good for machine control
FireWire - Don't know much about it, may be great but not widely available
PATA - I am looking into this as it is based on ISA bus. But not too motivated as that seems to be vanishing also.
FDD - same as PATA
SATA - may be viable, but most likely too much trouble.

Brings us to the NIC. It has been used for what I want to do, including available drivers for the PC side of things. (The link I posted in the first post shows a finished product of that which I desire). So for me, that is the hard side and its done already. I just need to come up with a suitable way to have a PIC talk to a NIC. In a fashion much faster then 115K. Now the ethernet capable PIC sounds VERY intresting. I will surf that a bit. Keep in mind I have NO idea what it takes to talk to a NIC. In my mind I think it must be pretty hard as I have read things like TCP/IP stack and UDP protocal. Lots more stuff I don't even want to think about.

Been over to the mother site. I seems that the 18f87j60 may be just the ticket. :)

Ethernet is not necessarily realtime. You can have very lengthy delays unless you are planning a one-on-one connection with no possibility of collisions, retransmissions, etc.

While I've been retired for 20+ years, I've been in a few thousand manufacturing facilities. (I ran the US subsidiary of a French machine tool builder.)

Are you wanting to control a CNC machine from a PC? Is the PIC going to be on the CNC machine or PC end of the link?

Hi Dave & Bert,
Dave
I am standing on the back of Bert's calves looking over his shoulder,(well figuratively anyway) watching as I want/need to do the same things, and am pretty sure he wants the PC to directly control the CNC as opposed to drip feeding it. After a while it is impractical to use ancient PCs as they wear out and fail too. New PCs can be had for 4-500 USD and that beats going Salvation Army shopping. but as Bert stated the ECP and other options have been killed (Thank's Mr. Gates).
Bert,
Controller cards which have Parallel ports are still available for pci bus.

http://images.frys.com/art/product/b...370288.box.GIFhttp://images.frys.com/art/misc/space.gif SYBA SD-PCI-1P DB25 PCI
Frys # 5370288

Hi,
As Dave says, Ethernet is not necessarily realtime, but it's my understanding that the Beckhoff "stuff" brings it pretty close. Their EtherCAT/TwinCAT technology can be used run multi-axis servo systems (yes, they have CNC controls based on their system) where a standard PC with their software is the control and talks to the servo-controllers and I/O units via Ethernet.

Apparently someone has integrated an open souce version of the EtherCAT library into EMC2 which is pretty cool though I have no idea of what it can and can't do and/or how deterministic it is. But since EMC2 runs on the RTAI kernel of Linux I'd guess it's pretty good. (Or is EtherLAB replacing RTAI?)

Now, I'm not sure what exactly you intend to so Bert. Are you planning on having EMC2 doing the motion control and sending velocity commands out over thru the Ethernet interface to the drives or whatever (ie one PIC per device) say 1000 times/second. Or are you envisioning a single PIC receiving multiaxis motion data?

Even if Ethernet in itself is 10Mb, 100Mb or even 1Gb there's no way you're going to be able to handle the data at any rate near that in any PIC that PBP supports.

Would you care to explain a bit on what you want to do on the PIC side? As you may know I've done a bit of work with the W5100 chip and I'm now in a state where I have my own development board:

Attachment 5861

It contains a PIC18LF46K22, the W5100 ethernet chip, place for SST25VF SPI flash memory and FTDI USART. I'll send you a blank board if you want.

The W5100 handles all the heavy lifting and supports TCP/IP, UDP and RAW so I guess it should be handle whatever protocol EtherLAB/EtherCAT is actually using. Obviosuly the W5100 adds a bit ($5) to the cost and ups the hardware complexity of the project a bit compared to a single chip solution like the 87J60.

The drawback with my board (for the application I envision you do doing) is that the W5100 talks to the PIC over SPI, this brings down the potential thru put of data but the W5100 supports bus interface as well but then it requires a boatload (25+) of I/O's from the PIC.

The W5100 contains 8k of memory so if you're trying to do the realtime stuff on the PIC you can use that memory as a buffer - but that kind of defeats the purpose of the realtime EtherLAB engine....

Anyway, I'll stop rambling now. But if you would care to elaborate a bit on what exactly is supposed to happen at the "PIC end" of the line perhaps we can come to a better conclusion on what might work and what won't.

/Henrik.

Quote:

---

Originally Posted by Charles Linquis

I use Lantronix XPorts and MatchPort AR parts. They aren't too easy to setup from the "serial side" (it is doable, however), and setup from the "network side" is a breeze. They work well and the nice thing about an XPort is the small size. Just supply 3.3V and a serial connection and you are good to go. They are about $50 each in small quantities.

---

Also agree, very good the Lantronix!!!

I have No problem with my desire to explain what I am trying to do, but clearly have a huge problem actually explaining it. Thanks Henrik for bringing some clarity to this for me. Here goes my next attempt:

This will be a direct 1 to 1 connection between my I/O card and the PC. So I am assuming there should be no collisions or contention on the bus.
The intention is this:
every 20uSec I want to send 4 bytes of data to a PIC, and receive 4 bytes back. So every 20uSec, there needs to be 8 bytes transferred of actual data.



The PIC will use the 4 bytes in 1 of several ways:

• simplest setup is a stepper driven machine. In this case the PIC will just transfer the bytes to ports as output.
• next case is servo driven machine. In this case hardware PWM will be updated to reflect the new values just received. So the PIC just transfers bytes to registors (I haven't given much thought to this case as my current needs are for stepper control)

In either case, there should be no real processing on the PIC side, just Move the data and wait for the next packet.

For the 4 bytes going back to the PC, this is just read a port and send the data. I think the PIC may be always 1 packet behind on the sent data. I am thinking after every transmission, a buffer is updated with new port data then waits for the next packet request from the PC.

There is NO motion control in the PIC itself, this is all done on the PC using EMC2 software. Step/DIR generation is all done on the PC. Each bit of 1 byte is the step value for 1 driver.

Hopefully this makes things at least a little bit clearer.

Thanks Henrik for the card offer, as yet I would have NO idea what to do with it, so I fear it would be a waste for me to accept it.

As for the choice of PIC, I feel like the idea of built in ethernet controller may solve the problem for me, but I don't know. I am clearly in the dark as to what it takes to have a successful exchange of data between a NIC and a PIC. If I need to use something like PIC32MX695F512L, then so be it. The program for this should not be intense, at least once the data has been received. I would prefer to use something more like 18F97J60, but just to keep it in the PBP family.

In a servo set-up, the amount of data may go up. But I can't see more then 8 bytes each way.

Quote:

---

Originally Posted by Archangel

After a while it is impractical to use ancient PCs as they wear out and fail too. New PCs can be had for 4-500 USD and that beats going Salvation Army shopping. but as Bert stated the ECP and other options have been killed (Thank's Mr. Gates).

---

I keep one very old PC going because of my Protek 220 oscilloscope card. I bought the motherboard just as ISA was disappearing from new PCs. It has ISA, PCI and one AGP slot so I'm able to use newer graphics cards and monitors with it.

Quote:

---

Originally Posted by Archangel

Controller cards which have Parallel ports are still available for pci bus.

---

Even for ISA - I usually deal with Byterunner because they've proven to be very knowledgeable over the years but I assume Bert is hoping to future-proof his design and, as you said, ancient PCs wear out.

I think I'd be looking at Single Board Computers for this application.

I agree with Dave about the single board computer. I still like the PC104 form.
Here is an example
http://pc104.winsystems.com/products/PCM-DSPIO.cfm

I am using SBC. you can pic them up pretty cheap (<$100 in most cases), and they are plenty powerful enough to run the linux stuff. Typically they have 1 PCI slot and some built in's. ALWAYS they have built in NIC. some have parallel either as a connector or actual DB25. They are starting to move away from PATA and only have SATA support.

My current project has 4G SSHDD and 1G ram. It is fan cooled, but even fanless can be had.

I would also like to be ablu to use a laptop instead of a dedicated SBC. This just for the ease of development. As you know, laptops are now having less and less connectivity.

Quote:

---

Originally Posted by cncmachineguy

I would also like to be ablu to use a laptop instead of a dedicated SBC. This just for the ease of development. As you know, laptops are now having less and less connectivity.

---

Go to Byterunner and scroll to the bottom of the page.

Hi Bert,
That was a very good explanation of you desired application, thanks! Following are some more or less random comments.

Quote:

---

This will be a direct 1 to 1 connection between my I/O card and the PC. So I am assuming there should be no collisions or contention on the bus.

---

No, there should be no collisions if the only connection is from NIC to PIC with a cross over cable.

Quote:

---

The intention is this:
every 20uSec I want to send 4 bytes of data to a PIC, and receive 4 bytes back. So every 20uSec, there needs to be 8 bytes transferred of actual data.

---

Wow, let's see here. 8 bytes of data every 20us, that's 50000*8=400 000 bytes per seconds or a bandwidth of 3.2Mbit - ethernet can handle it but there's no way you're going to get that thruput with say the W5100 interfaced to the PIC via SPI (like I have on my board). If using the parallel bus it might work but still, 400kb per second is quite a bit of data to handle for a PIC.

If you run the PIC at 64Mhz one instrucion cycle is 62.5ns so you got 320 instructions between each update. In those 320 instruction you must retreive 4 bytes from the Ethernet buffer, write those to your ports/registers, read some other ports/registers and write 4bytes to the ethernet buffer and do other housekeeping stuff - that might be doable.

However, I have no idea about how EtherCAT actually works, if it runs "on" TCP/IP etc or if it's a lower level protocol. But if it runs "on" TCP/IP and you're running the TCP/IP stack on the PIC (like you're going to have to do with the 87J60 for example) the job is certanly MUCH bigger than reading/writing the 4 bytes to/from the ethernet buffer. Even if you only have a single device on your "network" the network itself is not point-to-point so there's overhead there in any case.

I'm not saying it can not be done, in fact I have no idea if it can or can not be done but I'm pretty sure it's going to hard.

Quote:

---

The PIC will use the 4 bytes in 1 of several ways:

• simplest setup is a stepper driven machine. In this case the PIC will just transfer the bytes to ports as output.
• next case is servo driven machine. In this case hardware PWM will be updated to reflect the new values just received. So the PIC just transfers bytes to registors (I haven't given much thought to this case as my current needs are for stepper control)

In either case, there should be no real processing on the PIC side, just Move the data and wait for the next packet.

---

Sounds simple but if your doing the TCP/IP stuff in the PIC you still have to handle the overhead of the protocol itself, parse incomming packages and construct outgoing packages, calculate checksums etc etc. Again, I don't have the specific details on EtherCAT but I bet it's going to be something like that.

The beauty of something like the W5100 is that it handles the low level stuff for you but still you must move those 400kBytes of data in and out of the W5100 every second and I'm not sure how "real time" that chip itself is.

Quote:

---

Hopefully this makes things at least a little bit clearer.

---

It does, a lot, and it was pretty much as I thought.

Quote:

---

Thanks Henrik for the card offer, as yet I would have NO idea what to do with it, so I fear it would be a waste for me to accept it.

---

No problem, it's simply not going to do what you need for the stepper version anyway[/quote]

Quote:

---

In a servo set-up, the amount of data may go up. But I can't see more then 8 bytes each way.

---

Actually I think the servo-setup may be easier than the stepper. In this case the PC still handles the motion control stuff, calculates trajectories, does the PID etc. The output from the PID is then the desired velocity of the motor. Because the inertia of the mechanical system is quite large there's no need to update the velocity tens of thousands of times per seconds. 1000-1500 or so should be more than enough. So let's say you tranfer a 16bit velocity command plus 4 bytes of control data to the device and reads 6 bytes of control data back 1500 times per second. That's "only" 18kB/second compared to 400kB/second for the stepper version.

By the way, that velocity aproach is exactly how EMC2 works internally even when it outputs step and direction signals thru the LPT-port. There's a "step and direction driver" that gets a velocity command from the motion control engine at the rate specified, the step and direction driver then outputs the step frequency. So I think you're going to have a hard time getting EMC2 and EtherCAT software to spit out data at 20us intervals reliably but that's just me thinking out loud.... I haven't even used EMC2 so take it for what it is.

I'll be following whatever you fdo with great interest!

/Henrik.

Thanks for the in depth reply Henrik. I had to laugh at myself when you did the math for me, that is usually my first thing when looking at others stuff. It has been brought to my attention the 20Us is WAY faster then I need. I will be very happy at 40, and could live with 60. Does that help things any?

Hi Bert,
Sure it helps. Doubling the cycle time cuts the amount of data per time unit in half so you're going from 400kB/sec to 200kB/sec or 133kB/sec if you go to 60us - so yes, it helps. If it's doable? I still have my doubts and as I said earlier you still have to get the PC to spit out the ethernet packages fast enough. It's not just a matter of the bandwidth, you've got that covered, but since there is no buffer your 4byte packages must go out with exactly 40us between them. And again, your not sending just those 4 bytes of actual data - there's much more to it than that.

I've done some reading and although there's a LOT of variables having an impact on performance I found some numbers in section 8.0.2 of this document. They mention a possible cycle frequency of up to 25kHz on a 2GHz system which puts it right on your 40us mark.

I hate being sceptic but in this case I am (but please proove me wrong will you!). Like I said earlier, the servo-setup where velocity updates are being sent at ms intervals would be easier.

/Henrik.

Bert has me interested in this stuff as well. Here are some links for for the EtherCat protocol, and for a slave product by Beckhoff that works with a PIC chip and C code.

EtherCat: Attachment 5865

EtherCat slave info: http://download.beckhoff.com/downloa...L9800_V1i1.pdf

EtherCat EL9800 Board: http://www.ethercat.org/en/products/...2DEABC1474.htm

EtherCat EL9800 Board PDF: http://download.beckhoff.com/downloa...00e_Ver3.0.pdf

Ooh good stuff Walter!! Thanks for that. Not sure if I am reading correctly, but it seems the pic stuff has a 24 for them comm part then an 18 for the brain? Maybe something about the PHL(?) or physical hardware layer or something like that. Man there is a lot to know about this.

I guess the EL9800 microchip based board is designed to accept the "Postage Stamp" board by Beckhoff, which does the ethernet handling with 2 Micrel and a proprietary EL-CAT (U400) chip. Yeah, the PIC18 reference has me confused too, as it sure looks PIC24 ish to me. Maybe there was an earlier board with a PIC18??

Attachment 5866

I had hair on my head as of yesterday, but now I seem to have it mostly pulled out. I am sure glad I have you guys here helping me with this. There is LOTS to read this weekend.

@ Dave (macracket), missed your post before, must have crossed posted. I looked quickly at the link, is that a SBC or something to hook to my SBC?

Can be a single board, but the cool thing about the 104 form factor is they are stack-able if you need to expand the system (add more stuff).
http://en.wikipedia.org/wiki/PC/104
And because they are popular in industry they will commonly have RS232 and LPT built onto the main (first) board and run in high temperature environments.

Its not often that this happens, but after careful consideration I have decided this is far beyond my reach at this time. There is a lot of things to learn about ethernet, etherCat, and how it all works together.

Thank you all for the help!