Lost on LAN line

[HenrikOlsson]

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

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.

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.

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.

Hopefully this makes things at least a little bit clearer.

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

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]

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.

[cncmachineguy]

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?

[HenrikOlsson]

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.