Lost on LAN line

[cncmachineguy]

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

[dhouston]

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?

[Archangel]

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.

SYBA SD-PCI-1P DB25 PCI
Frys # 5370288

[HenrikOlsson]

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:

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.

[dhouston]

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.

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.

[mackrackit]

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

[cncmachineguy]

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.

[dhouston]

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.

[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?