The driver can sustain the full 100 mbits.
To calculate the theoretical maximum
Start with the 1500 packet size, add the 12 inter-frame-gap + the frame overhead ( 8 for preamble + 14 for header + 4 for the CRC )
then calculate the theoretical max speed:
100 Mbit/s / 8 bits in a byte * (1500/1538)
= 12.19 MB/sec
The throughput will decrease when packets get smaller (the minimal ethernet packet would have 46 bytes payload @ 6,85 MBps).
I have done some research about EtherCAT, again. I'm currently applying for a membership in the EtherCAT Technology Group (ETG) so that I have access to the full protocol documentation. What I have found out so far from the Q&A on the ETG web site:
Implementing a master is free (no royalties to Beckhoff) and is possible with the current driver software. It also requires no special hardware, the EthPhy acessory board would do.
Implementing a slave device (ESC = EtherCAT slave controller) is more difficult. It also requires to pay a license fee to Beckhoff if no IC is used that already includes the license (i.e. only the P2, two PHYs and the magnetics)
There are some ready-to-use ESC chips available such as the original ET1100 from Beckhoff or the LAN9252 from Microchip. The price of theese ICs already includes the license fee. A LAN9252 is ~$11 for single and down to $7 for large quantities. It has an SPI interface which can easily interface to a P2 or even a P1.
So technically, there is no need for a complex ESC driver that has to modify the ethernet packet on the fly and calculate two checksums, one for RX and one for TX. The price of one P2 is around the same as a P1+LAN9252 combination, so there is no real economical reason for a bit-banging solution with the P2, either. But it would be possible, I think, and it would be really cool. I think no other of-the-shelf CPU can do this.
The only problem I see is the CRC latency already mentioned here. The RX packet needs to be fully received and the CRC verified before the TX packet CRC can be calculated. That means more than 32 bits or 320ns latency not including the RX elastic buffers for compensating the clock drift. I have to check if that is still within the specs.
How complex is EtherCAT compared to TCP/IP? Or another way to ask that is would TCP/IP ever be considered here? I've used Modbus TCP a little. Never programmed for it though.
I wrapped my head around that issue already. I could not find any reference to what the maximum permitted delay for an ethercat node is... that would be really interesting - i look forward to you finding it out.
besides, it would be tough... probably 2 COGs in tandem with LUT sharing (or passing data via pin repository mode) working quasi-synchronous ( i bet you will have at least 1 word delay, 32 bits, if not two words) (i am not sure if going to 16 bits ethernet banging instead of 32 would make a difference if possible at all{ as the timing is quite tight already})
what is the benefit of doing it all inside the P2, besides saving a few pennys on the slave chip (minus the licence fee)
one thing i can think of is that it would ensure crc protection while you would not have that over a SPI link(right?)
TCP/IP and EtherCAT are two completely different worlds. TCP/IP is meant for general purpose data transmission from "keystroke events" (single bytes) up to transferring gigabyte large files. The complexity of TCP/IP is not the TCprotocol itself, that's relatively easy. It's all the "side effects" you have to support: how to get the IP address... ARP, DHCP, name servers, gateways and so on.
EtherCAT is real time. There is only one packet transmitted per time frame. It includes all data for all slaves at once. The size of each sub-packet is fixed and small. There is no need to repeat data in the case of a lost or corrupted packet because outdated data is useless anyway. It's simply dropped and you wait for the next transmission.
There's also no need for adressing. There are no switches or hubs. Although the physical topology can be a chain or a star or any mix of it in the end it's all flattened out. each slave forwards the packet to the next in the daisy chain and the last one sends it back to the master.
So in theory it's much simpler as TCP/IP. But I have to check the documentation before I promise anything. Big companies always have the power to screw everything up complexity-wise. The original MODBUS specification is a nightmare. It's several hundreds of pages and I didn't understand anything. Then I read the docs of a Yaskawa VFD that supports MODBUS. It was explained much simpler and clearer, there.
@Simonius said:
besides, it would be tough... probably 2 COGs in tandem with LUT sharing working quasi-synchronous ( i bet you will have at least 1 word delay, 32 bits, if not two words)
No, it's actually a lot easier, I mean it takes more computing power because two different CRCs have to be calculated at the same time. But it's more predictable than running an arbitrary full duplex protocol like TCP/IP. There, an RX packet can arrive anytime in the middle while transmitting a TX packet. So you need two cogs because you never know.
With EtherCAT there is a fixed time schedule. You always know in advance when the next packet will arrive and the relation RX to TX is also always fixed. So only one cog can do the job. You need a second cog for the packet that is returned to the master, though, unless you implement a physical ring that closes the loop from the last slave back to the master with an extra cable. That is possible but nobody does it because it would require an Y-cable or a second RJ45 jack at the master. The loopback-cog does not need to process anything but just passes the incoming data 1:1 unmodified.
what is the benefit of doing it all inside the P2, besides saving a few pennys on the slave chip (minus the licence fee)
Eternal glory in the hacker's hall of fame. (and possibly unending hatred from Beckhoff)
And BTW, I don't like Microchip ICs. They always try to build "egg-laying wool-pigs" that fit all imaginable requirements but are rediculously complex. It possibly takes about the same time to read just the data sheet of the LAN9252 (329 pages not including the Appnotes for the drivers) and to implement everything from scratch.
from what i grasped about etherCAT, you will have no time to process the packet in whole to resend it.... you have to start sending the very packet you are currently receiving, which a few clocks delay max.... that is, real on the fly processing and insertion of data and crc at the right time....but i might be wrong
i reread your posts and figured that we both are saying the same thing... i am just not so confident that it can be pulled off, as the timing gets very tight, don't you think? and that in only one COG?hmm
I propose the following. COGrx does receive the packet, pushes each Word to the HUB + calculate the CRC as usual + copy the stream to the PIN repository, when the time has come to insert INTO the packet, send that to the pin repository instead
COGtx does transmit a packet as it alsways does but instead of the HUB memory, it taps the pin repository for fresh data, CRC as usual.... at the very end of the procedure there is a flag raised on COGrx that COGtx can read, whenever a CRC error occurs. in that case, the transmitted packet is aborted or it's CRC voluntarily corrupted. 2 COGs, 32+something bits of delay. should work. await the info on the specs
The great thing about fieldbus standards....there are so many to choose from...wait, what?
In any given manufacturing environment, the maintenance personnel might have to contend with CAN, ModBus, EtherCAT, Sercos, ProfiBus, Ethernet, yada, yada.
Typically a Windows front-end and menu after menu, listing meaningless gobbledegook.
It's a mess. Nobody knows how to work on anything anymore....they have to call for assistance.
And who needs to be throwing 100Mb/s around in a sea of EMR?
@ManAtWork said:
The original MODBUS specification is a nightmare. It's several hundreds of pages and I didn't understand anything. Then I read the docs of a Yaskawa VFD that supports MODBUS. It was explained much simpler and clearer, there.
Most Modbus slaves are only partial implementations. Hell, even masters don't fully implement it. It's no big deal in that respect. One of the advantages of being freely open, no one is enforcing compliance to a particular level. Just Read IR (FC4) and R/W HR (FC3,FC16) is enough.
There's even a formal rejection for unsupported functions - Exception code 1.
PS: I have programmed for Modbus RTU (RS232 and RS485).
Modbus is OK for slow devices like VFDs, relays, solenoids... But it's too slow for realtime processing and synchronization of multiple high-bandwith devices like servos who have to follow a precision trajectory. It's all no problem in an automation application. You tell each servo the target position, it starts the move on its own and it sets a flag when it's ready. Only two data packets required once per second or so. But in a CNC machine you have to update the position of each axis every millisecond. For a five axis machine this is 10,000 packets per second.
To illustrate how EtherCAT works:
The master sends the packet with all output data for all slaves to the first slave. Slave 1 picks the data (subpacket M-Data 1) that's meant for him and makes a local copy. He then replaces that part of the packet with it's own input data (S-Data 1) which (eventually) goes to the master. Sending the resulting packet to slave number 2 starts as soon as possible while the packet from the master is still being received (overlapping). This is known as "fast forward" for ethernet switches, but is a bit more complicated as the packet is modified on-the-fly. Thus, a new CRC has to be generated each time.
Slave 2 and Slave 3 do the same and replace their output data with their input data. The last slave that has no more successor sends the packet back to the master via the second twisted pair line.
Not only has EtherCat a 100 times higher bit rate than a typical CAN or MODBUS network. The overlapping transmission makes it even faster. Transmitting all data to all devices takes only very little more time than transmitting a single packet.
Edit: BTW, source and destination addresses are also different for each packet. But they don't really matter as the packet is only sent point-to-point. There are no switches or hubs. Each node acts as repeater which sends a modifies packet to the next node in the chain.
@Simonius , if one cog has enough CPU power to do the processing then there is no reason to do it with two. It doesn't get easier that way. Adding shared LUTs or smart pin repositories are good tricks if they are necessary but they add complexity and delay. Taking the detour over hub RAM would add even more delay even if throughput is not the problem with the egg-beater.
At 100Mbit/s we have 2 cycles per bit if we run the P2 at 200MHz. So we have 64 cycles or 32 instructions to process one long. We need 8 CRCNIB instructions per CRC32 and need two of them. That's 20 instructions including the SETQ and REP setup. We have 12 left for feeding the serial smart pins and the SPLITW/MERGEW. It's going to get tight but should be possible.
The problem is that we have to replace a part of the packet with local data and that part can start and end at any byte boudary, i.e. it's not necessarily longword aligned. Maybe this can be implemented with a clever SKIPF pattern. Or, as the byte boundaries are known in advance, we could "JIT-compile" the assembly code to fit the subpacket boundaries.
@Mickster said:
The great thing about fieldbus standards....there are so many to choose from...wait, what?
In any given manufacturing environment, the maintenance personnel might have to contend with CAN, ModBus, EtherCAT, Sercos, ProfiBus, Ethernet, yada, yada.
That's a perfect argument for throwing it all overboard, sieving out the one that can fit all cases that are really necessary, and then start implementing from scratch instead of lego-brick programming with all the available libraries to avoid bloating.
And who needs to be throwing 100Mb/s around in a sea of EMR?
Because it doesn't cost much more than a 1Mb/s ESD protected RS485 transceiver.
@ManAtWork said:
operators of industrial machines don't want to deal with network administration or care about software settings for the connections. They don't even know what an IP address is. They want to plug in the cable, press a button and it has to work. Period.
>
So what? The Beckhoff device manager is designed as reference and diagnosis tool, so it has to support everything and display and allow to change any bit. But nobody enforces me to copy this.
I know there is a minimum of supported commands and features that every slave device has to support. So I can not just randomly select a sub-set and call it "EtherCat compatible". But I can always provide shortcuts and hide most of the complexity from the end user. I especially see no need to set any IP or other address. Enumeration can be done by the order the slaves are connected with the cables. If I tell the user to connect the X axis first, Y second and Z last then all he has to do is to plug in the cables in the correct order. Everything in the software can then be identified and addressed automatically.
How is this helpful to anybody? You mean the P2 can compute a position value for 6 axes in 5us? Nice. But this has nothing to do with the subject. And I don't know why the implementation of somebody else needs 1000µs. Should I care?
EtherCAT is an absolute joke. Engineers are invited to "training seminars" which are nothing more than sales pitches, then return to their bosses saying that this is the future and they need to standardize on this stuff.
This time last year, the lack of EtherCAT controller chips was a disaster for many companies. Worked for me because I got a nice standing order to eliminate this Beckhoff garbage. I follow this stuff online and the horror stories are unbelievable.
Same goes for those who are suckered in to Siemens, AB, etc.
NONE of these companies care that your production-line is dead on a 3rd-shift or that you need to wait 6 months for a replacement CPU.
No reason for everything to not be OTS (off-the-shelf), standard MCUs and RS485 comms. Anything can be achieved.
My point about the P2? It's because that's what the "big-boys" do. You and I both know that these numbers are practically meaningless but Omron (since they bought-out Delta-Tau's PMAC): "World's fastest controller - 5 Axes - 25us!"
Gullible engineers buy into this stuff - because they're clueless and ain't spending their own money
Repeat orders come from robust reliability (coming from a machine-tool manufacturer).
All I see today is apathy. Engineers are helpless because nothing can be repaired anymore.
Input dies? Yeah we know it's an opto-coupler, less than a buck.
"Oh we need to order a new Beckhoff/Siemens/AB 8-input module, should be here next week"
Reality and the fact that some people defend this nonsense is pretty sad.
@Mickster, I'm totally with you. I know that all those campaigns of the big companies are just marketing b'llsh't. They print glossy paper leaflets to make it look nice and impress the bosses and the workers have to deal with the trouble. I know that. But that has nothing to do with me and the way I want to do it.
NONE of these companies care that your production-line is dead on a 3rd-shift or that you need to wait 6 months for a replacement CPU.
That is one more reason to do it with the P2 and without any proprietary chips that may become unavailable in the next crisis.
EtherCAT was invented by Beckoff but it's an open standard. You are not enforced to buy anything from Beckhoff. I heared roumors that the Chinese government also pushes EtherCAT. There are more and more servo systems available with EtherCat that are becoming cheaper and cheaper. I think in 10 years drives with analogue or step/direction input will become rare. So sooner or later we will have to look something to replace analogue or step/dir signals. I think, EtherCat is the right choice, at least from the technical point of view. The hardware is cheap as it's the same as any PC uses. It's a bit expensive in terms of used cogs in the P2. But the strategical advantage not to depend on any proprietary ICs does counterweight this.
And I apologize for my some would say exaggerated optimism. I may end up in cold water as soon I am confronted with the full complexity. But that's how projects get started. If you're pessimistic you won't start anything new...
Another reason why I vote for EtherCat is: I can get rid of my internal high speed bus which connects multiple axis and IO modules to the main module. Until now I have implemented this with some sort of SPI bus but with RS422/485 drivers to improve noise immunity. With etherCat I could combine the internal bus and the external field bus into one. If no long cable is used I simply connect the magnetics to the PHY chips back-to-back.
The optional field bus module is then an almost empty board with just an RJ45 jack instead of a complex bridge between two different protocols.
That is one more reason to do it with the P2 and without any proprietary chips that may become unavailable in the next crisis.
Bear in mind, however, that by chosing this path you make your product totally dependent on THE chip (P2) from THE company (Parallax). Now, that looks like a single point of failure, big time (unless you stockpile the P2 to be on a safe side at any given time - that may require substantial investment up front).
Are they any more immune than the others in case of a crisis ?
That is one more reason to do it with the P2 and without any proprietary chips that may become unavailable in the next crisis.
Bear in mind, however, that by chosing this path you make your product totally dependent on THE chip (P2) from THE company (Parallax). Now, that looks like a single point of failure, big time (unless you stockpile the P2 to be on a safe side at any given time - that may require substantial investment up front).
Are they any more immune than the others in case of a crisis ?
Weren't Parallax the first to open-source a MCU (P1)?
We know who we are dealing with and I would wager any amount that they would have us covered.
I am absolutely certain that analogue is going nowhere. Jacob Tal, Chuck Lewin and Peter Nachtwey still swear by it. Although Nachtwey has retired, he still communicates. He tells me that they can't live with the jitter of EtherCAT. Of course, the way Beckhoff sugar-coat it: "it's only a little bit pregnant". His RMC200 features an 18bit analog motor command
Even state-of-the-art drives have all the standard analogue commands whereas all the big Fieldbuses are options.
No matter how big/critical the project, there's no-way on earth the customer is going to put spares on the shelf:
My equivalent of this is a MAX491 xceiver which I double-up on (redundancy) as I strive to achieve my concept of MTTR-ZH (mean time to repair - zero hours)
We need a revolution, darnit and the P1 & P2 need to be at the heart of it. Time to cut the cr@p.
That is one more reason to do it with the P2 and without any proprietary chips that may become unavailable in the next crisis.
Bear in mind, however, that by chosing this path you make your product totally dependent on THE chip (P2) from THE company (Parallax). Now, that looks like a single point of failure, big time (unless you stockpile the P2 to be on a safe side at any given time - that may require substantial investment up front).
Are they any more immune than the others in case of a crisis ?
Weren't Parallax the first to open-source a MCU (P1)?
We know who we are dealing with and I would wager any amount that they would have us covered.
I'll bite on that one. Can you name just a single company, other than Parallax themselves, that actually did put a single P1 on the market ?
On the second one, I admire the weight that statement bears but virtually nothing can be taken for granted these days. One can for sure promise much more than one can deliver. I've witnessed a situation when a replacement of just one person (a president) within a company resulted in a total company policy reversal. Many people were more than unhappy, to put it mildly. I am really short on assumptions since then.
I'll bite on that one. Can you name just a single company, other than Parallax themselves, that actually did put a single P1 on the market ?
On the second one, I admire the weight that statement bears but virtually nothing can be taken for granted these days. One can for sure promise much more than one can deliver. I've witnessed a situation when a replacement of just one person (a president) within a company resulted in a total company policy reversal. Many people were more than unhappy, to put it mildly. I am really short on assumptions since then.
No but they're clearly all about open-source. I'm sure that if things suddenly went pear-shaped at Parallax, they would quickly hand over the reins to some other house. That's the impression I get, anyway.
This time last year, my customer placed an order for 11 complete Beckhoff controls for ASAP delivery. They got one unit in March 2023. Meanwhile P2-Edges were available, next-day, from Digikey UK.
It's the big-names that I'm wary of.
Comments
The driver can sustain the full 100 mbits.
To calculate the theoretical maximum
Start with the 1500 packet size, add the 12 inter-frame-gap + the frame overhead ( 8 for preamble + 14 for header + 4 for the CRC )
then calculate the theoretical max speed:
100 Mbit/s / 8 bits in a byte * (1500/1538)
= 12.19 MB/sec
The throughput will decrease when packets get smaller (the minimal ethernet packet would have 46 bytes payload @ 6,85 MBps).
I have done some research about EtherCAT, again. I'm currently applying for a membership in the EtherCAT Technology Group (ETG) so that I have access to the full protocol documentation. What I have found out so far from the Q&A on the ETG web site:
So technically, there is no need for a complex ESC driver that has to modify the ethernet packet on the fly and calculate two checksums, one for RX and one for TX. The price of one P2 is around the same as a P1+LAN9252 combination, so there is no real economical reason for a bit-banging solution with the P2, either. But it would be possible, I think, and it would be really cool.
I think no other of-the-shelf CPU can do this.
The only problem I see is the CRC latency already mentioned here. The RX packet needs to be fully received and the CRC verified before the TX packet CRC can be calculated. That means more than 32 bits or 320ns latency not including the RX elastic buffers for compensating the clock drift. I have to check if that is still within the specs.
How complex is EtherCAT compared to TCP/IP? Or another way to ask that is would TCP/IP ever be considered here? I've used Modbus TCP a little. Never programmed for it though.
I wrapped my head around that issue already. I could not find any reference to what the maximum permitted delay for an ethercat node is... that would be really interesting - i look forward to you finding it out.
besides, it would be tough... probably 2 COGs in tandem with LUT sharing (or passing data via pin repository mode) working quasi-synchronous ( i bet you will have at least 1 word delay, 32 bits, if not two words) (i am not sure if going to 16 bits ethernet banging instead of 32 would make a difference if possible at all{ as the timing is quite tight already})
what is the benefit of doing it all inside the P2, besides saving a few pennys on the slave chip (minus the licence fee)
one thing i can think of is that it would ensure crc protection while you would not have that over a SPI link(right?)
TCP/IP and EtherCAT are two completely different worlds. TCP/IP is meant for general purpose data transmission from "keystroke events" (single bytes) up to transferring gigabyte large files. The complexity of TCP/IP is not the TCprotocol itself, that's relatively easy. It's all the "side effects" you have to support: how to get the IP address... ARP, DHCP, name servers, gateways and so on.
EtherCAT is real time. There is only one packet transmitted per time frame. It includes all data for all slaves at once. The size of each sub-packet is fixed and small. There is no need to repeat data in the case of a lost or corrupted packet because outdated data is useless anyway. It's simply dropped and you wait for the next transmission.
There's also no need for adressing. There are no switches or hubs. Although the physical topology can be a chain or a star or any mix of it in the end it's all flattened out. each slave forwards the packet to the next in the daisy chain and the last one sends it back to the master.
So in theory it's much simpler as TCP/IP. But I have to check the documentation before I promise anything. Big companies always have the power to screw everything up complexity-wise. The original MODBUS specification is a nightmare. It's several hundreds of pages and I didn't understand anything. Then I read the docs of a Yaskawa VFD that supports MODBUS. It was explained much simpler and clearer, there.
No, it's actually a lot easier, I mean it takes more computing power because two different CRCs have to be calculated at the same time. But it's more predictable than running an arbitrary full duplex protocol like TCP/IP. There, an RX packet can arrive anytime in the middle while transmitting a TX packet. So you need two cogs because you never know.
With EtherCAT there is a fixed time schedule. You always know in advance when the next packet will arrive and the relation RX to TX is also always fixed. So only one cog can do the job. You need a second cog for the packet that is returned to the master, though, unless you implement a physical ring that closes the loop from the last slave back to the master with an extra cable. That is possible but nobody does it because it would require an Y-cable or a second RJ45 jack at the master. The loopback-cog does not need to process anything but just passes the incoming data 1:1 unmodified.
Eternal glory in the hacker's hall of fame.
(and possibly unending hatred from Beckhoff)
And BTW, I don't like Microchip ICs. They always try to build "egg-laying wool-pigs" that fit all imaginable requirements but are rediculously complex. It possibly takes about the same time to read just the data sheet of the LAN9252 (329 pages not including the Appnotes for the drivers) and to implement everything from scratch.
from what i grasped about etherCAT, you will have no time to process the packet in whole to resend it.... you have to start sending the very packet you are currently receiving, which a few clocks delay max.... that is, real on the fly processing and insertion of data and crc at the right time....but i might be wrong
i reread your posts and figured that we both are saying the same thing... i am just not so confident that it can be pulled off, as the timing gets very tight, don't you think? and that in only one COG?hmm
I propose the following. COGrx does receive the packet, pushes each Word to the HUB + calculate the CRC as usual + copy the stream to the PIN repository, when the time has come to insert INTO the packet, send that to the pin repository instead
COGtx does transmit a packet as it alsways does but instead of the HUB memory, it taps the pin repository for fresh data, CRC as usual.... at the very end of the procedure there is a flag raised on COGrx that COGtx can read, whenever a CRC error occurs. in that case, the transmitted packet is aborted or it's CRC voluntarily corrupted. 2 COGs, 32+something bits of delay. should work. await the info on the specs
The great thing about fieldbus standards....there are so many to choose from...wait, what?
In any given manufacturing environment, the maintenance personnel might have to contend with CAN, ModBus, EtherCAT, Sercos, ProfiBus, Ethernet, yada, yada.
Typically a Windows front-end and menu after menu, listing meaningless gobbledegook.
It's a mess. Nobody knows how to work on anything anymore....they have to call for assistance.
And who needs to be throwing 100Mb/s around in a sea of EMR?
Most Modbus slaves are only partial implementations. Hell, even masters don't fully implement it. It's no big deal in that respect. One of the advantages of being freely open, no one is enforcing compliance to a particular level. Just Read IR (FC4) and R/W HR (FC3,FC16) is enough.
There's even a formal rejection for unsupported functions - Exception code 1.
PS: I have programmed for Modbus RTU (RS232 and RS485).
Modbus is OK for slow devices like VFDs, relays, solenoids... But it's too slow for realtime processing and synchronization of multiple high-bandwith devices like servos who have to follow a precision trajectory. It's all no problem in an automation application. You tell each servo the target position, it starts the move on its own and it sets a flag when it's ready. Only two data packets required once per second or so. But in a CNC machine you have to update the position of each axis every millisecond. For a five axis machine this is 10,000 packets per second.
To illustrate how EtherCAT works:
The master sends the packet with all output data for all slaves to the first slave. Slave 1 picks the data (subpacket M-Data 1) that's meant for him and makes a local copy. He then replaces that part of the packet with it's own input data (S-Data 1) which (eventually) goes to the master. Sending the resulting packet to slave number 2 starts as soon as possible while the packet from the master is still being received (overlapping). This is known as "fast forward" for ethernet switches, but is a bit more complicated as the packet is modified on-the-fly. Thus, a new CRC has to be generated each time.
Slave 2 and Slave 3 do the same and replace their output data with their input data. The last slave that has no more successor sends the packet back to the master via the second twisted pair line.
Not only has EtherCat a 100 times higher bit rate than a typical CAN or MODBUS network. The overlapping transmission makes it even faster. Transmitting all data to all devices takes only very little more time than transmitting a single packet.
Edit: BTW, source and destination addresses are also different for each packet. But they don't really matter as the packet is only sent point-to-point. There are no switches or hubs. Each node acts as repeater which sends a modifies packet to the next node in the chain.
@Simonius , if one cog has enough CPU power to do the processing then there is no reason to do it with two. It doesn't get easier that way. Adding shared LUTs or smart pin repositories are good tricks if they are necessary but they add complexity and delay. Taking the detour over hub RAM would add even more delay even if throughput is not the problem with the egg-beater.
At 100Mbit/s we have 2 cycles per bit if we run the P2 at 200MHz. So we have 64 cycles or 32 instructions to process one long. We need 8 CRCNIB instructions per CRC32 and need two of them. That's 20 instructions including the SETQ and REP setup. We have 12 left for feeding the serial smart pins and the SPLITW/MERGEW. It's going to get tight but should be possible.
The problem is that we have to replace a part of the packet with local data and that part can start and end at any byte boudary, i.e. it's not necessarily longword aligned. Maybe this can be implemented with a clever SKIPF pattern. Or, as the byte boundaries are known in advance, we could "JIT-compile" the assembly code to fit the subpacket boundaries.
That's a perfect argument for throwing it all overboard, sieving out the one that can fit all cases that are really necessary, and then start implementing from scratch instead of lego-brick programming with all the available libraries to avoid bloating.
Because it doesn't cost much more than a 1Mb/s ESD protected RS485 transceiver.
And it goes on and on and on...
P2: 6 axes <5uS
So what? The Beckhoff device manager is designed as reference and diagnosis tool, so it has to support everything and display and allow to change any bit. But nobody enforces me to copy this.
I know there is a minimum of supported commands and features that every slave device has to support. So I can not just randomly select a sub-set and call it "EtherCat compatible". But I can always provide shortcuts and hide most of the complexity from the end user. I especially see no need to set any IP or other address. Enumeration can be done by the order the slaves are connected with the cables. If I tell the user to connect the X axis first, Y second and Z last then all he has to do is to plug in the cables in the correct order. Everything in the software can then be identified and addressed automatically.
How is this helpful to anybody? You mean the P2 can compute a position value for 6 axes in 5us? Nice. But this has nothing to do with the subject. And I don't know why the implementation of somebody else needs 1000µs. Should I care?
@ManAtWork
EtherCAT is an absolute joke. Engineers are invited to "training seminars" which are nothing more than sales pitches, then return to their bosses saying that this is the future and they need to standardize on this stuff.
This time last year, the lack of EtherCAT controller chips was a disaster for many companies. Worked for me because I got a nice standing order to eliminate this Beckhoff garbage. I follow this stuff online and the horror stories are unbelievable.
Same goes for those who are suckered in to Siemens, AB, etc.
NONE of these companies care that your production-line is dead on a 3rd-shift or that you need to wait 6 months for a replacement CPU.
No reason for everything to not be OTS (off-the-shelf), standard MCUs and RS485 comms. Anything can be achieved.
My point about the P2? It's because that's what the "big-boys" do. You and I both know that these numbers are practically meaningless but Omron (since they bought-out Delta-Tau's PMAC): "World's fastest controller - 5 Axes - 25us!"
Gullible engineers buy into this stuff - because they're clueless and ain't spending their own money
Hence the reason I suggested Modbus TCP rather than RTU.
Modbus still talks "coils"
Protocols created by committees.
No reason why a remote system should be harder to follow/implement than a local system.
Header: Byte
Address: Byte
Control: High nibble: What to do
Low nibble: Number of data bytes to follow
Data: Whatever number of bytes
Checksum or CRC.
Job done.
Why make life difficult.....oh that's right, we need to be locked in to a big name vendor.
Mickster,
Interoperability is an actual selling point.
evanh
Selling the first product is a sales job.
Repeat orders come from robust reliability (coming from a machine-tool manufacturer).
All I see today is apathy. Engineers are helpless because nothing can be repaired anymore.
Input dies? Yeah we know it's an opto-coupler, less than a buck.
"Oh we need to order a new Beckhoff/Siemens/AB 8-input module, should be here next week"
Reality and the fact that some people defend this nonsense is pretty sad.
By selling point, I meant it is looked for in a product when comparing specs ... But I'm sure you already understood what I meant.
@Mickster, I'm totally with you. I know that all those campaigns of the big companies are just marketing b'llsh't. They print glossy paper leaflets to make it look nice and impress the bosses and the workers have to deal with the trouble. I know that. But that has nothing to do with me and the way I want to do it.
That is one more reason to do it with the P2 and without any proprietary chips that may become unavailable in the next crisis.
EtherCAT was invented by Beckoff but it's an open standard. You are not enforced to buy anything from Beckhoff. I heared roumors that the Chinese government also pushes EtherCAT. There are more and more servo systems available with EtherCat that are becoming cheaper and cheaper. I think in 10 years drives with analogue or step/direction input will become rare. So sooner or later we will have to look something to replace analogue or step/dir signals. I think, EtherCat is the right choice, at least from the technical point of view. The hardware is cheap as it's the same as any PC uses. It's a bit expensive in terms of used cogs in the P2. But the strategical advantage not to depend on any proprietary ICs does counterweight this.
And I apologize for my some would say exaggerated optimism. I may end up in cold water as soon I am confronted with the full complexity. But that's how projects get started. If you're pessimistic you won't start anything new...
Another reason why I vote for EtherCat is: I can get rid of my internal high speed bus which connects multiple axis and IO modules to the main module. Until now I have implemented this with some sort of SPI bus but with RS422/485 drivers to improve noise immunity. With etherCat I could combine the internal bus and the external field bus into one. If no long cable is used I simply connect the magnetics to the PHY chips back-to-back.
The optional field bus module is then an almost empty board with just an RJ45 jack instead of a complex bridge between two different protocols.
Bear in mind, however, that by chosing this path you make your product totally dependent on THE chip (P2) from THE company (Parallax). Now, that looks like a single point of failure, big time (unless you stockpile the P2 to be on a safe side at any given time - that may require substantial investment up front).
Are they any more immune than the others in case of a crisis ?
Weren't Parallax the first to open-source a MCU (P1)?
We know who we are dealing with and I would wager any amount that they would have us covered.
@ManAtWork
Apologies for derailing the thread
I am absolutely certain that analogue is going nowhere. Jacob Tal, Chuck Lewin and Peter Nachtwey still swear by it. Although Nachtwey has retired, he still communicates. He tells me that they can't live with the jitter of EtherCAT. Of course, the way Beckhoff sugar-coat it: "it's only a little bit pregnant". His RMC200 features an 18bit analog motor command
Even state-of-the-art drives have all the standard analogue commands whereas all the big Fieldbuses are options.
No matter how big/critical the project, there's no-way on earth the customer is going to put spares on the shelf:
My equivalent of this is a MAX491 xceiver which I double-up on (redundancy) as I strive to achieve my concept of MTTR-ZH (mean time to repair - zero hours)
We need a revolution, darnit and the P1 & P2 need to be at the heart of it. Time to cut the cr@p.
I'll bite on that one. Can you name just a single company, other than Parallax themselves, that actually did put a single P1 on the market ?
On the second one, I admire the weight that statement bears but virtually nothing can be taken for granted these days. One can for sure promise much more than one can deliver. I've witnessed a situation when a replacement of just one person (a president) within a company resulted in a total company policy reversal. Many people were more than unhappy, to put it mildly. I am really short on assumptions since then.
No but they're clearly all about open-source. I'm sure that if things suddenly went pear-shaped at Parallax, they would quickly hand over the reins to some other house. That's the impression I get, anyway.
This time last year, my customer placed an order for 11 complete Beckhoff controls for ASAP delivery. They got one unit in March 2023. Meanwhile P2-Edges were available, next-day, from Digikey UK.
It's the big-names that I'm wary of.