Re: [Emc-users] Ethernet I/O
Very interesting topic! Kenneth Lerman wrote: > Is 100BaseT ethernet full duplex? (I think it is.) > > That's easy to find: sudo mii-tool Password: eth0: negotiated 100baseTx-FD flow-control, link ok FD = Full Duplex > In principle, one could make a "hub" (not technically a hub) that daisy > chained cables. So, the master would output to slave 1 abd input from slave > N. Slave 1 would input from the master and output to slave 2. Slave 2 would > input from slave 1 and output to slave 2... Slave N would input from slave > N-1 and output to the master. > > That's daisy chain isn't it? The trouble is that low cost encoder won't handle traffic for advanced motor or whatever controllers. > Each slave would read its input, process it if appropriate and pass it on to > the next in the link. It would also inject its output into the ring. > > Think of it as a token ring using ethernet hardware that is cheap and > readily available. > > The master would continuosly send poll packets around the ring. > > Mix of high and slow devices is asking for trouble IMO. My preference would be to have individual connections to machine components based on speed. Perhaps using two buses, one for slow devices and one for faster ones. Industry offers a number of hardware solutions for digital IO mentioned on this mailing list. Some could be adapted for handling bus type communications between PC and peripherals. However, they are not standardized with number of IO lines, buffers, number of registers, protocols, open source/architecture, etc. This brings up another option, build an open source EMC controller PCI[e] card with slow, medium and high speed ports that could be used to control buses. Speeds would need to be determined based on what is required for machine world. If build with an FPGA, it would be very flexible and handle a lot of logic and speed and could be programmed for different needs: use with lathe, 3D routers and torch machines, or even run real time functions. It would be easier to have one "programmable" card that would connect to most sensors, encoders, etc. than to find encoders and other such stuff with ethernet built in. I know, I'm asking too much, who has time and resources to build all this :-) > An alternative is to use a standard hub and have the master poll each of the > slaves, in turn. > > I don't see this as something to use with encoders, but I could imagine its > being used with smart motor controllers or multi-axis controllers (like > Jon's). > > In either case we are looking at significant change from current more or less standard parallel port. For now it's easy to find PCI cards with parallel ports which is good for the time being. PCI bus will soon be replaced with PCIe. Will that bring cards with parallel ports is yet to be seen. Even then, parallel port is just not the right thing. It was never meant to be used for anything fast not to mention electric and mechanical characteristics of the port. I don't think ethernet components will be low cost enough to attract home builders to it for a while so we'll keep looking for low cost IO ports. > Ken > Good job all of you guys out there. I learn a lot from you every day. -- Rafael - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Off Topic, Broaching
Has CNC changed the way keyways are made? I need to make some keyways for my mill conversion, and I have no tooling so far for doing it. Since I will may be buying tooling, I want to explore the options in order to make the best investment. I actually prefer not having keyways and going with set screws on countersinks. Anyone have thoughts on this? Thanks. -- Kirk Wallace (California, USA http://www.wallacecompany.com/machine_shop/ Hardinge HNC lathe Bridgeport mill conversion pending Zubal lathe conversion pending) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] HNC Pictures
In case anyone is interested, I have posted new pictures, including the new spindle line filter and ferrite bead, to my HNC lathe site: http://www.wallacecompany.com/cnc_lathe/HNC/ -- Kirk Wallace (California, USA http://www.wallacecompany.com/machine_shop/ Hardinge HNC lathe Bridgeport mill conversion pending Zubal lathe conversion pending) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Peter C. Wallace wrote: > On Mon, 29 Oct 2007, Jon Elson wrote: > >>The idea is that 100 mbit/sec ethernet is fast. What other >>RS485 device do you have that runs that fast? > > > Of course a RS-485 link can have smaller packets, and may actually have much > better real time performance. (a single 10 MBps RS-485 link will have much > better performance than 100 BT Ethernet connected to a single encoder) > > Also 100BT with its MLT3 encoding is not as electrically robust as isolated > RS-485 or 10BT. > > Ethernet is great for broadcast but I don't think so good for collecting data > from a large number of separate real time devices (say encoders) > Yes, I think this would be a bad way to do things. Having a single motion control board that interfaces by Ethernet, as I have been envisioning, would have a lot of advantages. It keeps the sampling of all the encoders synchronized, it compresses all the information interchange into a couple packets, it saves on hardware. Putting a separate ethernet interface into each encoder is a great way to sell a lot of hardware. > I think Ethernet would be a really good way to connect a multi channel motion > controller to a PC where the large packet size is not such nuisance. You > would > likely need a separate Ethernet card from the main network connection. RTnet, for instance, gets around this to some extent. But, that is one way to do it, have 2 ethernet ports on the computer, one for RT, one for the local net. Otherwise some kind of router needs to be used to keep outside traffic from flooding the RT segment. Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Dave Engvall wrote: > Jon, Rafael, et al > > IIRC CAN is 1 Mbit/sec. Well, that is at least possible, but we can work out what the performance would be. With 8 byte packets, you can't even send all the encoder positions for 4 axes in one packet, as that is 12 bytes. Anyway, for a 4-axis system, we need to read 12 bytes of position, and then send 8 bytes of velocity command to a PPMC or UPC, and 12 bytes to a UPC. They all have 3 bytes of sense input, and 1 or 2 bytes of digital output. So, a minimum of 15 bytes to read, and a minimum of 9 bytes to write. So, 15 + 9 bytes is 24, and at 1 MBit/sec, that is 192 us. Given all the required overhead to read and write multiple packets, it is already pretty close to chewing up a whole millisecond, and there's no way it could handle even 5 KHz servo update rate. So, I really don't think CAN is a good candidate. It severely limits the possible complexity and/or speed of the system. A worst-case system might be 2 encoder counters, 2 DACs, and 4 DIO cards. That would be 404 bytes total, for 3.2 ms, not counting ANY overhead. So, such a system would probably be limited to a 200 Hz servo update rate. The same data transfer, again ignoring all protocol overhead, on 100 MBit/sec Ethernet, would only be 32 us, which is much more reasonable. And, you get galvanic isolation of the ethernet, too! Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] zero motion homing in program
Jeff, Thanks for the response. I guess its not as simple as I had hoped. As you have probably already guessed, I was in the process of trying to do a little lathe work on my mill by writing some programs to utilize the rotary axis as the lathe spindle. I guess this is just one of many reasons why everybody isn't doing it. (I haven't completely given up yet) The only real problem with the "windup" and "unwind" situation is the amount of time it takes to unwind. It is exactly analogous to using a late to thread with a threading dial (cut, retract tool, drop halfnuts, move carriage, repeat) compared to cutting threads without threading dial when you must leave the nuts engaged while you reverse the spindle and turn it the same number of turns you used while cutting the thread. It is just time... and someone, maybe my granny, once said "Life is just time and money, either one can be traded for the other" I always put a "cleanup" section at the end of my programs where I set the axes back to where I want them to be when I open EMC the next time and there I also set all the variables that I used back to zero. If I put the G92.1 command in the "Cleanup" section of the program that used the G92 command will that accomplish the same as putting the G92.1 in the "setup" or preamble of all the other programs? At 04:22 PM 10/29/2007, you wrote: >If you use this method, I recommend adding G92.1 (cancel and zero G92 >offsets for all axes) in the preamble of all your gcode files. >Otherwise, the first "G92 A0" in your program will erroneously apply >offsets for other axes that were previously set, even in a previous run >of emc. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problems Compiling/Running - Update
A little bit more info:
When this function is called:
retval = rtapi_shmem_getptr(mem_id, &mem);
mem_id = 1. Upon return, mem = 0x0 and retval = 0.
So it seems the shared memory system doesn't work properly as mem should
never be set to zero. This is pretty much the limit of my debugging
abilities.
Andy
Andrew Ayre wrote:
> Thanks. It seg faults at line 2350 in hal_lib.c:
>
> static int init_hal_data(void)
> {
> /* has the block already been initialized? */
> if (hal_data->version != 0) {
>
> It appears that hal_data is NULL at this point. Here is the call stack:
>
> hal/utils/halcmd_main.c:195 (main)
> hal/utils/halcmd.c:109 (halcmd_startup)
> hal/hal_lib.c:2350 (hal_init)
>
> Andy
>
> Jeff Epler wrote:
>> A system call trace (produced by using "strace") or a backtrace at the
>> time of the segmentation fault (produced using "gdb") would be helpful
>> in pinpointing the location of the problem.
>>
>> You can find information how to use these utilities on many pages on the
>> internet.
>>
>> Jeff
>>
>> -
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>>
>>
>
--
Andy
PGP Key ID: 0x67090A54
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problems Compiling/Running - Update
Thanks. It seg faults at line 2350 in hal_lib.c:
static int init_hal_data(void)
{
/* has the block already been initialized? */
if (hal_data->version != 0) {
It appears that hal_data is NULL at this point. Here is the call stack:
hal/utils/halcmd_main.c:195 (main)
hal/utils/halcmd.c:109 (halcmd_startup)
hal/hal_lib.c:2350 (hal_init)
Andy
Jeff Epler wrote:
> A system call trace (produced by using "strace") or a backtrace at the
> time of the segmentation fault (produced using "gdb") would be helpful
> in pinpointing the location of the problem.
>
> You can find information how to use these utilities on many pages on the
> internet.
>
> Jeff
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
--
Andy
PGP Key ID: 0x67090A54
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problems Compiling/Running - Update
A system call trace (produced by using "strace") or a backtrace at the time of the segmentation fault (produced using "gdb") would be helpful in pinpointing the location of the problem. You can find information how to use these utilities on many pages on the internet. Jeff - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problems Compiling/Running - Update
I have narrowed the problem down to this: [EMAIL PROTECTED]:~$ /usr/local/bin/halcmd help Segmentation fault [EMAIL PROTECTED]:~$ su Password: [EMAIL PROTECTED]:/home/andy# /usr/local/bin/halcmd help Use 'help ' for more details about each command Available commands: loadrt Load realtime module(s) then the rest of the help output follows. As you can see, it works for root but not for a regular user. I'm guessing there is a setup step missing. Any ideas on how to solve this? Thanks! Andy Jeff Epler wrote: > EMC 2.1.x is unlikely to work on Ubuntu 7.10. However, the development > version has been improved in various ways for compatability with newer > versions of Ubuntu. > > On Ubuntu 7.10 the default amount of "locked memory" for regular users > is too low. You can fix that problem by adding the line > hard memlock 20480 > to /etc/security/limits.conf as root. (it's necessary to log out > completely after making this change) > > However, the result of this problem is not an "insmod error", but > another error about creating shared memory areas which I don't recall. > In the case of insmod errors, the last few lines shown by "dmesg" are > usually most useful in determining what is going on. > > Jeff -- Andy PGP Key ID: 0x67090A54 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] x-axis lathe orientation
On Fri, Oct 19, 2007 at 11:17:45AM -0400, Jaime Pozo wrote: > Hi, > > Is there a way in AXIS-lathe to "invert" one axis > in the backplot drawing, that is to say, change the > x-axis orientation, to see it like a mirror? Not currently, sorry. I know it would make more sense on some lathes to have X pointing up instead of down, but nobody has implemented this option yet. Chris - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] var file source listing
On Mon, Oct 29, 2007 at 09:58:30AM -0500, Cecil Thomas wrote: > I guess I'm looking for the "reverse directory" for the .var file. Please see: http://www.linuxcnc.org/docview/2.2/html/gcode_main.html#sub:Parameters - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] zero motion homing in program
Unfortunately, emc doesn't handle the repeating nature of rotational axes very well. I feel that the ultimate solution is for an A-axis traverse move to always move less than one revolution, even if the axis is "wound up" by a move to A3600. If this approach is adopted, then unwinding would be as simple as: G0 A0 .. but that's for the future, not for today. For now, I you can use G92 offsets for this purpose. If you program "G92 A0", then the G92 coordinate system offset is modified so that the current position of the A axis is now called 0. If you use this method, I recommend adding G92.1 (cancel and zero G92 offsets for all axes) in the preamble of all your gcode files. Otherwise, the first "G92 A0" in your program will erroneously apply offsets for other axes that were previously set, even in a previous run of emc. Another caveat when using G92 offsets in this way is that if you are actually at A3599 when you issue "G92 A0", subsequent moves will be offset by one degree. Finally, when you use this approach you have to make sure that the machine coordinate (the "wound up" coordinate) never reaches the limits set for the A axis in the inifile. You might also consider using relative coordinates, so that your command is in effect the number of revolutions to move, rather than the angle to move to. Jeff - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Is 100BaseT ethernet full duplex? (I think it is.)
In principle, one could make a "hub" (not technically a hub) that daisy
chained cables. So, the master would output to slave 1 abd input from slave
N. Slave 1 would input from the master and output to slave 2. Slave 2 would
input from slave 1 and output to slave 2... Slave N would input from slave
N-1 and output to the master.
Each slave would read its input, process it if appropriate and pass it on to
the next in the link. It would also inject its output into the ring.
Think of it as a token ring using ethernet hardware that is cheap and
readily available.
The master would continuosly send poll packets around the ring.
An alternative is to use a standard hub and have the master poll each of the
slaves, in turn.
I don't see this as something to use with encoders, but I could imagine its
being used with smart motor controllers or multi-axis controllers (like
Jon's).
Ken
[EMAIL PROTECTED]
Mark Kenny Products Company, LLC
55 Main Street Voice: (888)ISO-SEVO (888)476-7386
Newtown, CT 06470Fax: (203)426-9138
http://www.MarkKenny.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Peter C.
Wallace
Sent: Monday, October 29, 2007 2:16 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Ethernet I/O
On Mon, 29 Oct 2007, Alex Joni wrote:
> Date: Mon, 29 Oct 2007 21:00:22 +0200
> From: Alex Joni <[EMAIL PROTECTED]>
> Reply-To: "Enhanced Machine Controller (EMC)"
>
> To: "Enhanced Machine Controller (EMC)"
> Subject: Re: [Emc-users] Ethernet I/O
>
>> Umm, no... As master, no problem but slaves will be expensive:
>>
>> Ethercat slaves require either custom proprietry hardware or proprietary
>> IP
>
> Hmm, unfortunately I can't argue there.. been trying to find some prices
for
> a slave chip.
> I found some products, but no prices anywhere:
> - beckhoff ET1100, ET1200
> - ESC10, ESC20
> and some FPGA IP Core for Altera & Xilinx
>
> Maybe you have an idea how expensive they are?
No, I looked into this several months ago but was discouraged by the
hardware requirements. For the sychronization standards, I have more faith
that IEEE 1588 will get embedded in more Ethernet chips and processors with
Ethernet, for example:
Ethernet Transceiver with IEEE 1588 PTP Hardware Support from National Semi
(Product News, 17 Oct 2007 )
National Semiconductor has introduced its Ethernet transceiver with
integrated
hardware support for the IEEE 1588 Precision Time Protocol (PTP). For
applications in motion control, instrumentation, data acquisition and
telecommunications, the DP83640 precision PHYTER transceiver synchronizes
the
distributed network nodes to a master clock with 8-nanosecond accuracy.
The model DP83640 precision PHYTER transceiver synchronizes distributed
network nodes to master clock with 8 nsec accuracy and offers 100 Mb
synchronous Ethernet mode that eliminates any inaccuracy caused by clock
drift
between nodes. It integrates hardware time stamping of receive and transmit
packets, high-accuracy IEEE 1588 clock, and 12 GPIO pins that handle
simultaneous real-time events/multiple triggers. Device interfaces with any
microcontroller, FPGA, or ASIC with Ethernet MAC. The samples of the DP83640
transceiver are available now in a 48-pin LQFP. The DP83640 will be priced
at
$5.24 each in 1,000-unit quantities.
>
> Regards,
> Alex
>
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lis
Re: [Emc-users] Ethernet I/O
I finally found this reference:
http://www.rtcmagazine.com/home/article.php?id=100822&pg=2
"The slave controller chips are in the same range as standard Ethernet chips
(roughly $5 in quantity 10,000). The synchronization mechanism for EtherCAT
is already built in. Other solutions that rely on IEEE 1588 require an extra
chip. All together this makes EtherCAT a very affordable technology."
btw, I will be travelling in a couple of weeks to germany, might get in
contact with Beckhoff for some details.
Regards,
Alex
- Original Message -
From: "Peter C. Wallace" <[EMAIL PROTECTED]>
To: "Enhanced Machine Controller (EMC)"
Sent: Monday, October 29, 2007 9:16 PM
Subject: Re: [Emc-users] Ethernet I/O
> On Mon, 29 Oct 2007, Alex Joni wrote:
>
>> Date: Mon, 29 Oct 2007 21:00:22 +0200
>> From: Alex Joni <[EMAIL PROTECTED]>
>> Reply-To: "Enhanced Machine Controller (EMC)"
>>
>> To: "Enhanced Machine Controller (EMC)"
>> Subject: Re: [Emc-users] Ethernet I/O
>>
>>> Umm, no... As master, no problem but slaves will be expensive:
>>>
>>> Ethercat slaves require either custom proprietry hardware or proprietary
>>> IP
>>
>> Hmm, unfortunately I can't argue there.. been trying to find some prices
>> for
>> a slave chip.
>> I found some products, but no prices anywhere:
>> - beckhoff ET1100, ET1200
>> - ESC10, ESC20
>> and some FPGA IP Core for Altera & Xilinx
>>
>> Maybe you have an idea how expensive they are?
>
>
> No, I looked into this several months ago but was discouraged by the
> hardware requirements. For the sychronization standards, I have more faith
> that IEEE 1588 will get embedded in more Ethernet chips and processors
> with
> Ethernet, for example:
> Ethernet Transceiver with IEEE 1588 PTP Hardware Support from National
> Semi
> (Product News, 17 Oct 2007 )
>
> National Semiconductor has introduced its Ethernet transceiver with
> integrated
> hardware support for the IEEE 1588 Precision Time Protocol (PTP). For
> applications in motion control, instrumentation, data acquisition and
> telecommunications, the DP83640 precision PHYTER transceiver synchronizes
> the
> distributed network nodes to a master clock with 8-nanosecond accuracy.
>
>
> The model DP83640 precision PHYTER transceiver synchronizes distributed
> network nodes to master clock with 8 nsec accuracy and offers 100 Mb
> synchronous Ethernet mode that eliminates any inaccuracy caused by clock
> drift
> between nodes. It integrates hardware time stamping of receive and
> transmit
> packets, high-accuracy IEEE 1588 clock, and 12 GPIO pins that handle
> simultaneous real-time events/multiple triggers. Device interfaces with
> any
> microcontroller, FPGA, or ASIC with Ethernet MAC. The samples of the
> DP83640
> transceiver are available now in a 48-pin LQFP. The DP83640 will be priced
> at
> $5.24 each in 1,000-unit quantities.
>
>
>
>
>
>
>>
>> Regards,
>> Alex
>>
>>
>> -
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.15.12/1096 - Release Date:
> 10/27/2007 11:02 AM
>
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
On Mon, 29 Oct 2007, Alex Joni wrote:
> Date: Mon, 29 Oct 2007 21:00:22 +0200
> From: Alex Joni <[EMAIL PROTECTED]>
> Reply-To: "Enhanced Machine Controller (EMC)"
>
> To: "Enhanced Machine Controller (EMC)"
> Subject: Re: [Emc-users] Ethernet I/O
>
>> Umm, no... As master, no problem but slaves will be expensive:
>>
>> Ethercat slaves require either custom proprietry hardware or proprietary
>> IP
>
> Hmm, unfortunately I can't argue there.. been trying to find some prices for
> a slave chip.
> I found some products, but no prices anywhere:
> - beckhoff ET1100, ET1200
> - ESC10, ESC20
> and some FPGA IP Core for Altera & Xilinx
>
> Maybe you have an idea how expensive they are?
No, I looked into this several months ago but was discouraged by the
hardware requirements. For the sychronization standards, I have more faith
that IEEE 1588 will get embedded in more Ethernet chips and processors with
Ethernet, for example:
Ethernet Transceiver with IEEE 1588 PTP Hardware Support from National Semi
(Product News, 17 Oct 2007 )
National Semiconductor has introduced its Ethernet transceiver with integrated
hardware support for the IEEE 1588 Precision Time Protocol (PTP). For
applications in motion control, instrumentation, data acquisition and
telecommunications, the DP83640 precision PHYTER transceiver synchronizes the
distributed network nodes to a master clock with 8-nanosecond accuracy.
The model DP83640 precision PHYTER transceiver synchronizes distributed
network nodes to master clock with 8 nsec accuracy and offers 100 Mb
synchronous Ethernet mode that eliminates any inaccuracy caused by clock drift
between nodes. It integrates hardware time stamping of receive and transmit
packets, high-accuracy IEEE 1588 clock, and 12 GPIO pins that handle
simultaneous real-time events/multiple triggers. Device interfaces with any
microcontroller, FPGA, or ASIC with Ethernet MAC. The samples of the DP83640
transceiver are available now in a 48-pin LQFP. The DP83640 will be priced at
$5.24 each in 1,000-unit quantities.
>
> Regards,
> Alex
>
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
> Umm, no... As master, no problem but slaves will be expensive: > > Ethercat slaves require either custom proprietry hardware or proprietary > IP Hmm, unfortunately I can't argue there.. been trying to find some prices for a slave chip. I found some products, but no prices anywhere: - beckhoff ET1100, ET1200 - ESC10, ESC20 and some FPGA IP Core for Altera & Xilinx Maybe you have an idea how expensive they are? Regards, Alex - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
> I really think all of the thread raised issues have been addressed by
> Ethercat:
Umm, no... As master, no problem but slaves will be expensive:
Ethercat slaves require either custom proprietry hardware or proprietary IP
You can not use a generic ucontroller with Ethernet as a EtherCat slave.
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
On Mon, 29 Oct 2007, Jon Elson wrote:
> The idea is that 100 mbit/sec ethernet is fast. What other
> RS485 device do you have that runs that fast?
Of course a RS-485 link can have smaller packets, and may actually have much
better real time performance. (a single 10 MBps RS-485 link will have much
better performance than 100 BT Ethernet connected to a single encoder)
Also 100BT with its MLT3 encoding is not as electrically robust as isolated
RS-485 or 10BT.
Ethernet is great for broadcast but I don't think so good for collecting data
from a large number of separate real time devices (say encoders)
I think Ethernet would be a really good way to connect a multi channel motion
controller to a PC where the large packet size is not such nuisance. You would
likely need a separate Ethernet card from the main network connection.
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
I really think all of the thread raised issues have been addressed by Ethercat: 1. it uses Ethernet (100MBps max) raw packages 2. there is an opensource Ethercat "Master", which runs under linux/RTAI (http://www.etherlab.org/en/ethercat/index.php) 3. you could command motion and IO devices using one Ethercat network 4. "Data for and from 100 servo axis can be updated with up to 10 kHz." 5. "Process data exchange with 1000 distributed digital I/O takes about 30 µs." 6. The packages are really simple packages, each device looks inside if there's anything for itself, otherwise the package gets passed on. "Due to these features EtherCAT can support almost any topology such as line, tree or star. " 7. "Since 100BASE-TX Ethernet physical layer is used, the distance between any two nodes can be up to 100 m (300 ft). Up to 65535 devices can be connected per segment. If an EtherCAT network is wired in ring configuration (requires two ports on the master device), it can provide cable redundancy." 8. "For synchronization a distributed clock mechanism is applied, which leads to very low jitters of significantly less than 1 µs even if the communication cycle jitters. Therefore EtherCAT does not require a special hardware in the master device and can be implemented in software on any standard Ethernet MAC, even without dedicated communication coprocessor." 9. While the master can be implemented in software on the PC, "EtherCAT slave controllers are available as code for different FPGAs and are also available as ASIC implementation." 10. Using ethercat one could drive the motors from HAL, and read back encoder information (this would assume 1-2 ethercat logical devices / axis). I (personally) would implement a single axis controller (analog output or stepgen, and encoder input) which can be commanded by Ethercat. Then you could join 2-9 of these, depending how many joints the machine has. For I/O I would use existing products for starters (e.g. from Beckhof). Regards, Alex PS: most of the quotes are form http://en.wikipedia.org/wiki/EtherCAT - Original Message - From: "Jon Elson" <[EMAIL PROTECTED]> To: "Enhanced Machine Controller (EMC)" Sent: Monday, October 29, 2007 7:44 PM Subject: Re: [Emc-users] Ethernet I/O > Erik Christiansen wrote: >> On Fri, Oct 26, 2007 at 08:37:47PM -0500, Javid Butler wrote: >> >>>The real problem is the endpoint device. There will have to be some way >>>to >>>decode the signals from the ethernet into the actual drives. It will >>>probably be a while before cost effective drives are available with >>>ethernet >>>inputs. Until then we will have to use decoders that provide translation >>>of >>>the ethernet commands to individual bits such as are on the parallel >>>port. >> >> >> Is it essential that it be ethernet? If Jon's custom host controller had >> one or more RS485 ports (preferably 4-wire full-duplex), then any fast >> microcontroller with one or more serial ports could potentially serve as >> the endpoint controller. >> > The idea is that 100 mbit/sec ethernet is fast. What other > RS485 device do you have that runs that fast? >> With on-board multiple-channel PWM generators (e.g. with 64 MHz clock) & >> counter/timers to offload the CPU, and interrupt service routines being >> the natural order, a reasonably fast uC can handle velocity feedback, >> and calculating PID without too much fuss. (But high speed machine >> control may be more demanding.) >> > The main idea of this discussion os to PRESERVE the mode of > EMC2, and get around the disappearance of the parallel port. > There is no doubt that the entire motion control task, in fact > all of EMC2 except the GUI, could be moved to one of these ARM > micros. > And, by spoon-feeding the G-code in large chunks, there's be no > need for a fast I/O channel. But, that is not waht I was trying > to do! > >> If ethernet is used, it'd surely be necessary to be able to DMA the data >> into the micro, or the benefit of 100 Mb/s would be lost. Now we'd need >> an ARM chip as axis controller? Incidentally, if linux is to run on the >> host, then ARM would be a better choice than the NXP beast? (Though >> eCos is well endowed in the ISR area, and more suited to real-time.) > This is all handled by these ARM7 micros, they are an entire PC > on one chip, except for video. The NXP LPC2300 IS an ARM7 CPU. > They also have ARM9 if you need even more. Their problem is > getting working silicon out of the lab. > > Jon > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > >
Re: [Emc-users] Ethernet I/O
CAN is indeed a maximum 1Mbps, however about 50% of that is overhead, so the actual data bandwidth is more like a max of 500kbps. This is over a distance of something like 40 meters. CAN only defines the physical connection and message frame format. All the bit stuffing, sync, acknowlegements and limited retransmits are handled in hardware, but your application has to process messages that arrive fast enough for your application. Nearly all CAN controllers implement message filtering in hardware as well, reducing the number of messages that your application has to process. There is a max of 8 bytes in a message frame. The hardware implementation is quite a bit more sophisticated than a UART. Andy Jon Elson wrote: > Rafael Skodlar wrote: > >> I would not want to rely on UDP for real time applications unless it's >> used on an isolated network with a limited number of well behaving >> nodes. > Yes, you would have to do it that way. > >> Gigabit ethernet would be better but then which microcontroller will be >> able to run with it? 32 bit only: >> http://www.freescale.com/webapp/sps/site/application.jsp?nodeId=0220502E112E1F >> > This gets quite expensive, at least for a while still. >> How about using some other bus for real time applications? I'm sure >> there is a better bus for the price (CAN?) > I think CAN is much slower, and the hardware support is at a > MUCH lower level. It isn't much more sophisticated than a UART, > thus software overhead. > > Jon > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > > -- Andy PGP Key ID: 0x67090A54 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Jon, Rafael, et al IIRC CAN is 1 Mbit/sec. Philosophically I'd opt for KISS. (keep it simple stupid). No more complexity than is necessary to get the job done. To me that sounds a lot like raw packets point to point. Dave On Oct 29, 2007, at 10:33 AM, Jon Elson wrote: > Rafael Skodlar wrote: > >> I would not want to rely on UDP for real time applications unless >> it's >> used on an isolated network with a limited number of well behaving >> nodes. > Yes, you would have to do it that way. > >> >> Gigabit ethernet would be better but then which microcontroller >> will be >> able to run with it? 32 bit only: >> http://www.freescale.com/webapp/sps/site/application.jsp? >> nodeId=0220502E112E1F >> > This gets quite expensive, at least for a while still. >> How about using some other bus for real time applications? I'm sure >> there is a better bus for the price (CAN?) > I think CAN is much slower, and the hardware support is at a > MUCH lower level. It isn't much more sophisticated than a UART, > thus software overhead. > > Jon > > -- > --- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Erik Christiansen wrote: > On Fri, Oct 26, 2007 at 08:37:47PM -0500, Javid Butler wrote: > >>The real problem is the endpoint device. There will have to be some way to >>decode the signals from the ethernet into the actual drives. It will >>probably be a while before cost effective drives are available with ethernet >>inputs. Until then we will have to use decoders that provide translation of >>the ethernet commands to individual bits such as are on the parallel port. > > > Is it essential that it be ethernet? If Jon's custom host controller had > one or more RS485 ports (preferably 4-wire full-duplex), then any fast > microcontroller with one or more serial ports could potentially serve as > the endpoint controller. > The idea is that 100 mbit/sec ethernet is fast. What other RS485 device do you have that runs that fast? > With on-board multiple-channel PWM generators (e.g. with 64 MHz clock) & > counter/timers to offload the CPU, and interrupt service routines being > the natural order, a reasonably fast uC can handle velocity feedback, > and calculating PID without too much fuss. (But high speed machine > control may be more demanding.) > The main idea of this discussion os to PRESERVE the mode of EMC2, and get around the disappearance of the parallel port. There is no doubt that the entire motion control task, in fact all of EMC2 except the GUI, could be moved to one of these ARM micros. And, by spoon-feeding the G-code in large chunks, there's be no need for a fast I/O channel. But, that is not waht I was trying to do! > If ethernet is used, it'd surely be necessary to be able to DMA the data > into the micro, or the benefit of 100 Mb/s would be lost. Now we'd need > an ARM chip as axis controller? Incidentally, if linux is to run on the > host, then ARM would be a better choice than the NXP beast? (Though > eCos is well endowed in the ISR area, and more suited to real-time.) This is all handled by these ARM7 micros, they are an entire PC on one chip, except for video. The NXP LPC2300 IS an ARM7 CPU. They also have ARM9 if you need even more. Their problem is getting working silicon out of the lab. Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LRK Motors
Kirk Wallace wrote: > I am wondering if these motors, if scaled up could work as servo motors. > > http://www.torcman.de/peterslrk/LRK350-20-15_eng.html > http://www.torcman.de/peterslrk/index_eng.html > http://groups.yahoo.com/group/lrk-torquemax/ > > Being able to build my own servo motors is very appealing. > These are high-speed motors, not designed for positioning applications. I think you'd find there is a lot of torque and velocity ripple with them. Also, these motors are designed for intermittent use. Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Rafael Skodlar wrote: > I would not want to rely on UDP for real time applications unless it's > used on an isolated network with a limited number of well behaving > nodes. Yes, you would have to do it that way. > > Gigabit ethernet would be better but then which microcontroller will be > able to run with it? 32 bit only: > http://www.freescale.com/webapp/sps/site/application.jsp?nodeId=0220502E112E1F > This gets quite expensive, at least for a while still. > How about using some other bus for real time applications? I'm sure > there is a better bus for the price (CAN?) I think CAN is much slower, and the hardware support is at a MUCH lower level. It isn't much more sophisticated than a UART, thus software overhead. Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Stephen Wille Padnos wrote: > Jon Elson wrote: >>As long as you could throttle traffic on that ethernet segment, >>so a network file transfer, for instance, couldn't bog down the >>ethernet, then that would work. >> > > No, it wouldn't (not necessarily). > You'd also have to set the MTU pretty low. A single UDP packet of > 12.5kBytes takes 1ms to transmit on the wire. (12.5k * 8 bits = 100 > kbits = 1/1000 of 100 mbits/sec = 1msec) Even if you throttle large > transfers, and you can somehow convince multiple hosts on the segment to > all share the same "throttled pool" of bandwidth, a single large packet > can throw a wrench in the works. > 12.5 K bytes? I've never run a system with an MTU greater than 1536, I thought that was some generally agreed standard. My current system has it at 1500. 1536 * 8 bits = 12288, at 100 MBit/sec that would take 122 us plus overhead. Better not let more than one of those packets through per millisecond. That wouldn't really clobber the bandwidth for net transfers, though, you'd still get 1.5 MBytes/second throughput. There would not be multiple hosts, just the CNC machine and whatever was acting as a router for it. If you hooked a bunch of CNC control machines and their ethernet devices all on one segment, then you'd be asking for trouble. > >> But, I have no idea what would >>be involved in making the ethernet port driver and network stack >>RT compatible. Some time ago the RT stuff didn't do anything >>well except regularly-schenduled tasks, I think that is no >>longar a problem. But, the net driver would have to respond to >>interrupts whenever a packet came in. >> >> > > I think the base for interrupt-response threads is there - the current > HAL thread mechanism uses it to grab the timer interrupt. ADEOS can > route multiple interrupts (and multiple interrupt domains), and I'm > pretty sure RTAI also supports this. It's just not part of RTAPI or HAL. Yes, and I have no idea how hard it would be to put all that in. HAL might not need to know about it at all, but it seems RTAPI would. Now, maybe you could just start up the rtnet directly when the system boots, and let the drivers access rtnet without anybody else knowing its there. I certainly don't know all the implications, it would take some study! Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problems Compiling/Running - Update
Jeff, Thanks - I will give that a try. I think a shared memory error was in the mix. I also need to manually create the application menu entries. /usr/local/bin/emc is obvious. Are there any other executables that users should be able to run from the menu? Once I have this set up I will publish a blog entry with every single step to get EMC2 working so others can benefit from my efforts. thanks, Andy Jeff Epler wrote: > EMC 2.1.x is unlikely to work on Ubuntu 7.10. However, the development > version has been improved in various ways for compatability with newer > versions of Ubuntu. > > On Ubuntu 7.10 the default amount of "locked memory" for regular users > is too low. You can fix that problem by adding the line > hard memlock 20480 > to /etc/security/limits.conf as root. (it's necessary to log out > completely after making this change) > > However, the result of this problem is not an "insmod error", but > another error about creating shared memory areas which I don't recall. > In the case of insmod errors, the last few lines shown by "dmesg" are > usually most useful in determining what is going on. > > Jeff > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > > -- Andy PGP Key ID: 0x67090A54 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] var file source listing
This is a good explaination coordinate systems. http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CoordinateSystems The var file info is here http://www.isd.mel.nist.gov/documents/kramer/RS274NGC_3.pdf on page 13. - Original Message - From: "Cecil Thomas" <[EMAIL PROTECTED]> To: "Enhanced Machine Controller (EMC)" Sent: Monday, October 29, 2007 9:58 AM Subject: [Emc-users] var file source listing >I have searched the users and integrators manuals and can't find this > but maybe I've missed it. > > When strange things appear on startup of my axis or tkemc it is > usually because there is a value stored in the .var file. > If I zero out the strange numbers and save the .var file and restart > it usually fixes the problem. > > I would really like to trace down how the values got there in the > first place. Probably because I was doing on-the-job-training using > G54, G92, G28, G30, etc. without fully understanding what I was doing. > > If I had a listing of each variable and what G command causes it to > be changed I could then look at how I got into the situation in the > first place and maybe use the same command in the program to reset > the variable. > > I know that the discussions of each of the commands mentions which > variable it sets but to find the culprit I have to go through each > command searching for the variable number. > > I guess I'm looking for the "reverse directory" for the .var file. > > Thanks, > Cecil > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] var file source listing
I have searched the users and integrators manuals and can't find this but maybe I've missed it. When strange things appear on startup of my axis or tkemc it is usually because there is a value stored in the .var file. If I zero out the strange numbers and save the .var file and restart it usually fixes the problem. I would really like to trace down how the values got there in the first place. Probably because I was doing on-the-job-training using G54, G92, G28, G30, etc. without fully understanding what I was doing. If I had a listing of each variable and what G command causes it to be changed I could then look at how I got into the situation in the first place and maybe use the same command in the program to reset the variable. I know that the discussions of each of the commands mentions which variable it sets but to find the culprit I have to go through each command searching for the variable number. I guess I'm looking for the "reverse directory" for the .var file. Thanks, Cecil - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] zero motion homing in program
Is there some G command that works like the "HOME" button in AXIS or TKEMC that simply "makes the present position HOME" Without storing offsets in the .var file I am trying to do what appears to be a simple operation in g code but it seems to be over my head. here's the setup: I am using xyza with rotary axis parallel to X. I am using an endmill in the spindle to cut a square thread in a round bar in the chuck of the a axis. to cut a 5 pitch thread of 2 inch length the primary command line is G1 X2 A3600. There is obviously more to the program(multiple cuts with incremented Z etc) but this is the basic command. Here is the problem: When I finish the 10 revolutions along the 2 inch length I need to extract the tool and go back to where I started for the next cut. I can use G0 to extract the tool and bring it back to the beginning of the cut...But... If I use G0 A0 the darned thing sits there and "unwinds" the A axis 10 turns all the way back to 0 degrees. Since I went an integral multiplier of 360 degrees it is already sitting on "0" degrees of the part but EMC wants to "unwind" it back to 0 which is where it already is. What I would like: I would like to tell the controller "yeah, I know you think you are sitting on 3600 degrees but I'm telling you to forget that and from now 'til I tell you otherwise you are at 0 degrees which is home." Now I can increment the cut depth and repeat the process till the cut is done. I think what I am looking for is a way to "home" the axis with no movement. I tried G92 and G28 but they really don't Home the axis, they just store an offset in the .var file and offset the axis by that much on any move. The problem with that is that those offsets stay in the var file and when you bring up the controller the next time they are still there. So now every time I start EMC I have to remember to open the .var file and clean up all the junk BEFORE I start EMC. I know I could just increment the A command each time ...A3600 on pass one A7200 on pass two A9800 on pass three etc. but that seems like a workaround and besides when I finish the job I will have to "UNWIND" 30 revolutions or shut down EMC and start over. Bottom Line: Is there some G command that works like the "HOME" button in AXIS or TKEMC that simply "makes the present position HOME" Without storing offsets in the .var file I know I am going to be embarrassed by how simple the solution is but it has evaded me for the last 3 days so I am asking for help. Thanks, Cecil - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
The issue is at the PC end. In the past, parallel ports have been used, but it takes about a microsecond per byte to output to them. Ethernet has the advantage is that the controllers are PCI based and are a lot faster. Ken [EMAIL PROTECTED] Mark Kenny Products Company, LLC 55 Main Street Voice: (888)ISO-SEVO (888)476-7386 Newtown, CT 06470Fax: (203)426-9138 http://www.MarkKenny.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Erik Christiansen Sent: Monday, October 29, 2007 2:26 AM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] Ethernet I/O On Fri, Oct 26, 2007 at 08:37:47PM -0500, Javid Butler wrote: > The real problem is the endpoint device. There will have to be some way to > decode the signals from the ethernet into the actual drives. It will > probably be a while before cost effective drives are available with ethernet > inputs. Until then we will have to use decoders that provide translation of > the ethernet commands to individual bits such as are on the parallel port. Is it essential that it be ethernet? If Jon's custom host controller had one or more RS485 ports (preferably 4-wire full-duplex), then any fast microcontroller with one or more serial ports could potentially serve as the endpoint controller. With on-board multiple-channel PWM generators (e.g. with 64 MHz clock) & counter/timers to offload the CPU, and interrupt service routines being the natural order, a reasonably fast uC can handle velocity feedback, and calculating PID without too much fuss. (But high speed machine control may be more demanding.) Something like the AT90PWM3B, while only clocking 16 MIPS, needs only H-bridges and drivers added, to control a BLDC from its on-chip synchronised power stage controllers (specialised PWM). I haven't tried the ready made card at http://www.atmel.com/dyn/products/tools_card.asp?family_id=607&family_name=A VR+8%2DBit+RISC+&tool_id=3764 Estop can be fed directly into the output power stage controllers, if desired. The 100 MHz 8051 core also sounds interesting (as an axis controller) from a hardware point of view, but it's famously mismatched for 'C' coding, due to its stack limitations, and accumulator-centric architecture. The (possibly consequential) lack of gcc support, is probably the biggest hindrance to my eye, followed by the greater wealth of on-board peripherals on competing products. (Having used it professionally for nearly 2 decades, I have a soft spot for it, though.) A distributed architecture appeals because it is easier to upgrade/rebuild if the host controller only reads gcode and says "go to x, at speed s". There are no precison dc control voltages dodging EMI from power electrics either. Incidentally, with eeprom as well as flash in these microcontrollers, PID and other parameters can be stored in the drive, and updated via the host. (No panicked search for old data files when bringing a mothballed drive back into service.) Trying to make the serial communications super-hard real-time could be the hard way to do things. Where several axes need to be synchronised, one axis controller can put its encoder pulsetrain directly onto an RS485 synchronisation bus, and slaved axes feed that into on-chip hardware counters, either interrupting when the count is big enough to act on, or being read at the sample interval to check if the axis feed ratio is being maintained. Especially at high speeds, with high encoder line counts, a micro will still have to sample. (1 mS & 16 MIPS = 16,000 instructions per interval) The synchronising source can be chosen by selecting which axis controllers send, and which receive on a bus. The synchronisation busses would necessitate running a second cable between controllers, I figure. (I have some cat5 cable and some oil-resistant metallic flexible conduit, which I figured might do.) Would a 64 byte packet be required to issue a motion command to an axis controller, addressing included? (Since commands and status reports need not be nanosecond realtime, now that sync is on separate busses, does it hurt that an AT90PWM3B's 2Mb/s maximum baudrate extends transfer time to 320 uS for 64 bytes?) Let's send 32 bytes. ;-) Like the 8051, the AVRs have hardware address frame recognition, but must compare addresses in software, so an RS422-style point-point connection would be kinder. If ethernet is used, it'd surely be necessary to be able to DMA the data into the micro, or the benefit of 100 Mb/s would be lost. Now we'd need an ARM chip as axis controller? Incidentally, if linux is to run on the host, then ARM would be a better choice than the NXP beast? (Though eCos is well endowed in the ISR area, and more suited to real-time.) Erik - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files us
Re: [Emc-users] Ethernet I/O
What I had in mind is a DEDICATED ethernet segment. There would be no other traffic on it other than our RT traffic. I would NOT use UDP; I would use raw ethernet packets. Ken [EMAIL PROTECTED] Mark Kenny Products Company, LLC 55 Main Street Voice: (888)ISO-SEVO (888)476-7386 Newtown, CT 06470Fax: (203)426-9138 http://www.MarkKenny.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jon Elson Sent: Sunday, October 28, 2007 10:44 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] Ethernet I/O Kenneth Lerman wrote: > For me, the issue of RTnet is irrelevant. I would, instead, just want to use > the Linux driver. If we can get that to generate and receive ethernet frames > in real time, we are in business. > Well, that's the problem, it is NOT real time code. I don't know how far it is from being real time compatible, but I suspect there's a lot of things in there that might cause problems. > Then we could let the PC be a master and any peripherals be slaves. In the > case of the UPC board, there might be only one slave. The master would poll > each of the slaves as appropriate. As long as you could throttle traffic on that ethernet segment, so a network file transfer, for instance, couldn't bog down the ethernet, then that would work. But, I have no idea what would be involved in making the ethernet port driver and network stack RT compatible. Some time ago the RT stuff didn't do anything well except regularly-schenduled tasks, I think that is no longar a problem. But, the net driver would have to respond to interrupts whenever a packet came in. Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problems Compiling/Running - Update
EMC 2.1.x is unlikely to work on Ubuntu 7.10. However, the development version has been improved in various ways for compatability with newer versions of Ubuntu. On Ubuntu 7.10 the default amount of "locked memory" for regular users is too low. You can fix that problem by adding the line hard memlock 20480 to /etc/security/limits.conf as root. (it's necessary to log out completely after making this change) However, the result of this problem is not an "insmod error", but another error about creating shared memory areas which I don't recall. In the case of insmod errors, the last few lines shown by "dmesg" are usually most useful in determining what is going on. Jeff - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
