[Emc-users] Distributed communication interface ( UDP ?)

[Kate Alhola]

As new in this list i don't know is emc-users or emc-developers list
better for discussing new features.

At the moment there is many ongoing projects to do microcontroller
based BLDC or other servo motor controllers. Using some expensive
special board to convert EMC motor command to analog, then send to
microcontroller and convert back to digital is not the optimum way
to di it.

I have in my mind use some existing and low cost
comminication channele for it. Some alternatives are
Ethernet- IP/UDP, USB, SPI via printer port or serial port.

Ethernet is already in about all PC's and interface boards
are wery cheap. 100Mbit/s is enough fast and if there is no
other communication in segment it is more that enough real time.
There is many under 10 ( Euro/dollar) microcontrollers with
ethernet interface and there is numerous examples how to interface
some RTL8019 to common microcontrollers.

USB is even more common and really cheap, it exists many low cost
microcontrollers. Only open question is that what is latency and
can it be enough real time.

Printer port SPI would be easu to implement but how much system
resources it needs to clock all bits out ?

Serial ports can with 115200bps serve with 1000Hz command rate
even few motor controllers.


Ethernet/UDP looks a like most easy way to implement. There is
ready RTnet interface for it. Only bad limitation of RTnet
is that it requires special network card driver. In desktop
computer it is OK to just add 5Euro Ethernet board for RTnet
and hopefully it works also with equivalent PCcard
ethernet cards for laptops ?

UDP HAL module could be also used for connecting multiple PC-EMC
compurters so that someones just works as stepper/servo controllers
just by using UDP-HAL module to pass position commands to others.

To bypass RTnet network card limitations, we can use directly kernel
internal api's to send udp datagrams or to port relativelly simple rtsock
for rtai.

Least, i think that UDP with RTnet is easiest and most versatile way
to start.

Some cheap microcontrollers like AT91SAM7X256 can be also used as gateway
to other motor controller processors. It can then interface to these
with SPI, CAN etc.

For USB, it needs more evaluation what speed and latency is possile.
Is it speed enough even for 1000Hz positioning commands. The datarate
should be enouugh but latency getting encoder data back from
microcontrollers may be problem.


Kate

[Anders Wallin]

Post by Kate Alhola
Ethernet is already in about all PC's and interface boards
are wery cheap. 100Mbit/s is enough fast and if there is no
other communication in segment it is more that enough real time.
There is many under 10 ( Euro/dollar) microcontrollers with
ethernet interface and there is numerous examples how to interface
some RTL8019 to common microcontrollers.

An interesting topic! I know very little about RTnet etc. so excuse the
basic questions:

- would 10 Mbit suffice ? I've used microchip microcontrollers and I only
find their ENC28J60 for ethernet which is 10BASE-T

- is it possible to have multiple servodrives/devices connected to one
network card on the pc ? If that requires a hub, does the hub introduce
more latency ?

If someone writes an ethernet driver for EMC in the near future I could be
interested in doing an ethernet interface for my simple servodrive.

Anders

[Stephen Wille Padnos]

Post by Anders Wallin

Post by Kate Alhola
Ethernet is already in about all PC's and interface boards
are wery cheap. 100Mbit/s is enough fast and if there is no
other communication in segment it is more that enough real time.
There is many under 10 ( Euro/dollar) microcontrollers with
ethernet interface and there is numerous examples how to interface
some RTL8019 to common microcontrollers.

An interesting topic! I know very little about RTnet etc. so excuse the
- would 10 Mbit suffice ? I've used microchip microcontrollers and I only
find their ENC28J60 for ethernet which is 10BASE-T

The data rate is high enough, but some latency issues could crop up.
The standard for ethernet traffic requires a minimum 512-bit packet size
(including headers and stuff). There is an additional minimum
turnaround time (time from end of one packet until transmission of
another) of 96 bit times, and I think there's another gap in there, or a
header. I believe the total minimum packet time is 84 bytes, or 672
bits. With 10M ethernet, this is 67.2 microseconds per packet, and
there need to be two (a command and acknowledgement) per device. That
gets to be a lot of time spent waiting for data to move around,
especially if you have multiple ethernet-connected servo drives. Packet
sizes and gaps are all in bit-times though, so 100M ethernet has a 6.72
uS packet time, and that's only 0.672 uS for gigabit.

Post by Anders Wallin
- is it possible to have multiple servodrives/devices connected to one
network card on the pc ? If that requires a hub, does the hub introduce
more latency ?

I think a class II hub adds 92 bit times, but I'm not sure of that
number (my memory suffers from bit-fade ;) ). A switch adds more time,
since they generally do store-and-forward, which means that the whole
packet is received by the switch, then retransmitted to the target
port. You can have multiple devices on a hub, if you have a reasonably
well-defined master/slave protocol. I think RTNet treats ethernet kind
of like USB, with time slots reserved for each device on the network -
this prevents collision problems. Using a switch can offer one
advantage though - you can use full duplex. That allows a
response/status packet to be transmitted at the same time as the new
command, so devices that can get an interrupt when the MAC address is
detected can compose and send a return message as soon as the incoming
command packet is detected (without waiting for it to completely arrive).

Post by Anders Wallin
If someone writes an ethernet driver for EMC in the near future I could be
interested in doing an ethernet interface for my simple servodrive.

Evert Lammerts has one that's "almost ready for release" or close to
it. Several of us are waiting (im)patiently to see the code :)

Post by Anders Wallin
Anders

- Steve

[Kate Alhola]

Post by Anders Wallin

Post by Kate Alhola
Ethernet is already in about all PC's and interface boards
are wery cheap. 100Mbit/s is enough fast and if there is no
other communication in segment it is more that enough real time.
There is many under 10 ( Euro/dollar) microcontrollers with
ethernet interface and there is numerous examples how to interface
some RTL8019 to common microcontrollers.

An interesting topic! I know very little about RTnet etc. so excuse the
- would 10 Mbit suffice ? I've used microchip microcontrollers and I only
find their ENC28J60 for ethernet which is 10BASE-T

Yes, 10Mbit/s is enough. As mentioned other reply, You can send
one small frame under 100us and when you have a ethernet switch, even
cheap one, the PC can send packets to every target100Mbit/s
and switch will send them 10Mbit/s targets paralel.

There is no need, why you could not use EN28J60 but there is also
no need why to use inly it. It look like to be cheap ( 2.96Euro)
and small SO28/SSOP28 but as with SPI to host slower than
some popular Realtek RTL8019 or SMSC91C96 or 100Bit SMSC LAN9115
that have parallel/bus interface.

Post by Anders Wallin
- is it possible to have multiple servodrives/devices connected to one
network card on the pc ? If that requires a hub, does the hub introduce
more latency ?

At the moment, devices are normally Switches, not HUBs, they receive
packet from host 100Mhit/s and with this speed latency is meaningless
with 1ms sample interval.

Kate

[Eric H. Johnson]

Hi all,

I have a tool head with 4 tools or fixtures, where there is, or can be an X,
Y and Z offset between each of these fixtures. Only one of the fixtures have
changeable tools where length and diameter would apply. How do I configure
these offsets in EMC, so that if the system is set up (homes, etc.) for tool
1, when tools 2 is selected, the appropriate X, Y and Z offsets will be
applied so that this tool follows the same path as tool 1 given the same
G-Code file.

I thought there were reserved variables for this, but all I see are those
associated with G54 through G59. I guess that could work too, but I thought
there would be a way to apply X, Y and Z offsets based on the tool number
selected.

Regards,
Eric

[Jon Elson]

Post by Eric H. Johnson
Hi all,
I have a tool head with 4 tools or fixtures, where there is, or can be an X,
Y and Z offset between each of these fixtures. Only one of the fixtures have
changeable tools where length and diameter would apply. How do I configure
these offsets in EMC, so that if the system is set up (homes, etc.) for tool
1, when tools 2 is selected, the appropriate X, Y and Z offsets will be
applied so that this tool follows the same path as tool 1 given the same
G-Code file.
I thought there were reserved variables for this, but all I see are those
associated with G54 through G59. I guess that could work too, but I thought
there would be a way to apply X, Y and Z offsets based on the tool number
selected.

The G54 through G59 are WORK offsets. The tool table has diameter and
length
offsets for the TOOLS, and these are activated by "calling" the tool and
activating
either cutter radius compensation (G41 and G42) or tool length offset (G43).

G43 always adjusts the Z axis, only, and may be more appropriate when
different tools
are changed into the same spindle. The G54 through G59 are supposed to
be used for
as offsets to multiple workpieces or fixtures on the machine table, but
I don't see how
that is really different from an offset between different tools on the
head, other than the
signs being reversed. So, if an offset to the right of the workpiece
zero offset would have
a + X coordinate, then a tool that was to the right of the "home" tool
would need a
MINUS X offset. This would move the work table to the right (-X) to be
under the new tool.
As far as I know, the G54-G59 offsets accept XYZ values.

As the tool table works now (or as of a few weeks ago, anyway), it does
NOT have X and Y
offsets associated with each tool. At least X offsets are needed for
lathe work, so there are
plans to add this.

Jon

[Chris Radek]

Post by Jon Elson
As the tool table works now (or as of a few weeks ago, anyway), it does
NOT have X and Y
offsets associated with each tool. At least X offsets are needed for
lathe work, so there are
plans to add this.

If you have a lathe-format tool table, you get X and Z offsets.
This won't be in 2.0 but will be in 2.1 (it has been in cvs for
a bit now.)

http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?ToolTable

Chris

[Ed]

I tried to get fancy and install a drive tray and a removable drive in
my EMC controller box, I set the original drive as master on the
secondary cable and put the tray on the primary cable so I could quickly
change drives to experiment with the later Linux-EMC combo's. When I
installed a later version on the tray drive it messed with Grub on the
original drive and it will not boot. This would not be a problem except
I need the .ini and G-code files from the drive. The question is: How do
you mount the drive? The system is BDI2.16 I think the original drive
is now HDC and the tray drive is HDA. I would like to transfer the files
to the tray drive and use the original drive as a repository. Any help
apprieciated. Ed.

[Jon Elson]

Post by Ed
I tried to get fancy and install a drive tray and a removable drive in
my EMC controller box, I set the original drive as master on the
secondary cable and put the tray on the primary cable so I could quickly
change drives to experiment with the later Linux-EMC combo's. When I
installed a later version on the tray drive it messed with Grub on the
original drive and it will not boot. This would not be a problem except
I need the .ini and G-code files from the drive. The question is: How do
you mount the drive? The system is BDI2.16 I think the original drive
is now HDC and the tray drive is HDA. I would like to transfer the files
to the tray drive and use the original drive as a repository. Any help
apprieciated. Ed.

OK, with the botched drive as the secondary on the first IDE cable, it
should be
/dev/hdb

You can read the partition table (be very careful) with /sbin/fdisk.
You will need to be
root, or run it with sudo. The command would be something like :

# /sbin/fdisk /dev/hdb

Then, when it prompts you, type p, and it should list the partition
table. It may
be immediately apparent which partition is the main one, or you can just try
mounting all the partitions that show "Linux" in the System column to
see what
is in them. You'd do this with the following command :

# mount /dev/hdb5 /mnt/cdrom

(The /mnt/cdrom is using a pre-existing empty directory as the mount
point. If this
doesn't exist, you can create a new mount point with the command

# mkdir /mnt/newdisk

or something like that, and then retry the mount command with /mnt/newdisk
as the second parameter.)

Once the mount suceeds, you can list the directories with ls /mnt/cdrom and
work your way down to the directory with the files you need. To dismount
the disk, use :

# /umount /mnt/cdrom (You can specify either the mount point or the physical
partition name)

If the corrupted disk is /dev/hdc, then it is the master drive on the
2nd IDE cable.

Sure, a second drive that may not normally be mounted by the OS makes a
quick
way to save files.

Jon

[Ed]

Thanks to Jon Elson and Mark Pictor I am back to making chips!!! I had
tried to do some updating/experiment that blew up in my face and these
guys pulled me out of the fire. As to the experiment/update, I will have
a few questions and rants about Linux, and Ubuntu in particular. In a
couple of days I will have my laptop setup the way I like it and can
formulate the questions. Thanks again. Ed.

[Kenneth Lerman]

Well, I'm biased towards ethernet, because I'm very familiar with most of
the details.

But, USB might be better. It is clearly suitable for real time. There are
audio devices that use USB. There are also digital oscilloscopes that
connect to a PC with a USB.

Of course, to offer a third option, there is also firewire.

Ken

***@se-ltd.com
Mark Kenny Products Company, LLC
55 Main Street Voice: [phone]
Newtown, CT 06470 Fax: [phone]
http://www.MarkKenny.com


-----Original Message-----
From: emc-users-***@lists.sourceforge.net
[mailto:emc-users-***@lists.sourceforge.net]On Behalf Of Kate Alhola
Sent: Monday, August 14, 2006 11:28 AM
To: emc-***@lists.sourceforge.net
Subject: [Emc-users] Distributed communication interface ( UDP ?)



As new in this list i don't know is emc-users or emc-developers list
better for discussing new features.

At the moment there is many ongoing projects to do microcontroller
based BLDC or other servo motor controllers. Using some expensive
special board to convert EMC motor command to analog, then send to
microcontroller and convert back to digital is not the optimum way
to di it.

I have in my mind use some existing and low cost
comminication channele for it. Some alternatives are
Ethernet- IP/UDP, USB, SPI via printer port or serial port.

Ethernet is already in about all PC's and interface boards
are wery cheap. 100Mbit/s is enough fast and if there is no
other communication in segment it is more that enough real time.
There is many under 10 ( Euro/dollar) microcontrollers with
ethernet interface and there is numerous examples how to interface
some RTL8019 to common microcontrollers.

USB is even more common and really cheap, it exists many low cost
microcontrollers. Only open question is that what is latency and
can it be enough real time.

Printer port SPI would be easu to implement but how much system
resources it needs to clock all bits out ?

Serial ports can with 115200bps serve with 1000Hz command rate
even few motor controllers.


Ethernet/UDP looks a like most easy way to implement. There is
ready RTnet interface for it. Only bad limitation of RTnet
is that it requires special network card driver. In desktop
computer it is OK to just add 5Euro Ethernet board for RTnet
and hopefully it works also with equivalent PCcard
ethernet cards for laptops ?

UDP HAL module could be also used for connecting multiple PC-EMC
compurters so that someones just works as stepper/servo controllers
just by using UDP-HAL module to pass position commands to others.

To bypass RTnet network card limitations, we can use directly kernel
internal api's to send udp datagrams or to port relativelly simple rtsock
for rtai.

Least, i think that UDP with RTnet is easiest and most versatile way
to start.

Some cheap microcontrollers like AT91SAM7X256 can be also used as gateway
to other motor controller processors. It can then interface to these
with SPI, CAN etc.

For USB, it needs more evaluation what speed and latency is possile.
Is it speed enough even for 1000Hz positioning commands. The datarate
should be enouugh but latency getting encoder data back from
microcontrollers may be problem.


Kate


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[Thomas Formella]

BTW: Anybody heard of usb4rt ? Quote from the usb4rt website: 'USB for
Real-Time aims to provide a hard real-time capable implementation of an USB
stack on top of Linux/RTAI.'

http://developer.berlios.de/projects/usb4rt/

Thomas

Post by Kenneth Lerman
Well, I'm biased towards ethernet, because I'm very familiar with most of
the details.
But, USB might be better. It is clearly suitable for real time. There are
audio devices that use USB. There are also digital oscilloscopes that
connect to a PC with a USB.
Of course, to offer a third option, there is also firewire.
Ken
Mark Kenny Products Company, LLC
55 Main Street Voice: [phone]
Newtown, CT 06470 Fax: [phone]
http://www.MarkKenny.com

[Ray Henry]

Hi Thomas

I believe the critical word here is "aims." I am in agreement that
there is at least one advantage/drawback and at least one perceived
advantage to a USB enabled system.

The perceived advantage is that USB is everywhere and easily available.
There is however a wide range of USB implementations in hardware that
create the need for many, chip specific, drivers.

The advantage/drawback is the voltage supplied with the connection.
This is intended to provide power to light loads on the outboard end.
It can also be a isolation drawback if it is not properly handled when
the outboard device needs more power than a small cable and the USB
motherboard power supply can provide.

And then there are the designed in timing windows that have to be
overcome. SWP's recent post demonstrated ethernet's inherent advantage
in this respect. It was not designed to be the servant of an operating
system.

Rayh

Post by Thomas Formella
BTW: Anybody heard of usb4rt ? Quote from the usb4rt website: 'USB for
Real-Time aims to provide a hard real-time capable implementation of an USB
stack on top of Linux/RTAI.'
http://developer.berlios.de/projects/usb4rt/
Thomas

[Peter C. Wallace]

Post by Ray Henry
Hi Thomas
I believe the critical word here is "aims." I am in agreement that
there is at least one advantage/drawback and at least one perceived
advantage to a USB enabled system.
The perceived advantage is that USB is everywhere and easily available.
There is however a wide range of USB implementations in hardware that
create the need for many, chip specific, drivers.
The advantage/drawback is the voltage supplied with the connection.
This is intended to provide power to light loads on the outboard end.
It can also be a isolation drawback if it is not properly handled when
the outboard device needs more power than a small cable and the USB
motherboard power supply can provide.
And then there are the designed in timing windows that have to be
overcome. SWP's recent post demonstrated ethernet's inherent advantage
in this respect. It was not designed to be the servant of an operating
system.
Rayh

Post by Thomas Formella
BTW: Anybody heard of usb4rt ? Quote from the usb4rt website: 'USB for
Real-Time aims to provide a hard real-time capable implementation of an USB
stack on top of Linux/RTAI.'
http://developer.berlios.de/projects/usb4rt/
Thomas

For a distributed system, I think Ethernet has all the advantages over USB.

1. Electrical isolation - no ground loops - less easy to damage - better CMRR
for noise rejection

2. Optional POE give a reasonable amount of power for logic side of smart
amplifiers (USBs 2.5 W is really not enough)

3. 100 meter cable length (not that you would go that far)

4. Full duplex

5. Choice of 10,100,1000 Mbit second links (trade off noise immunity for
speed)
Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

[Thomas Formella]

Hi Ray,

thanks a lot for the explanation. It was not my intention to designate USB as
the superior bus for industrial realtime applications. I just wanted to point
out, that there's some (Open Source) research work done already...

BTW: There's an interesting "Feature Comparison Table for Servo Communications
Technologies" on the SERCOS webpage:
http://sercos.com/tech_info/popup/comparison_table.htm

Though, an comparison table on the SERCOS webpage is likely to be subjective,
maybe FireWire (IEEE-1394) is an alternative to RT-NET ?

There's an 'Open Source' RT-FireWire project also:

http://rtfirewire.dynamized.com/

It's a research work of the 'University of Twente, the Netherlands' and the
word 'aims' applies analogously to this project also...

Anyway, be it USB, Ethernet, SERCOS or FireWire: A *digital* interface
EMC2<>drives would be *very* interesting in my opinion...

Thomas

Post by Ray Henry
Hi Thomas
I believe the critical word here is "aims." I am in agreement that
there is at least one advantage/drawback and at least one perceived
advantage to a USB enabled system.
The perceived advantage is that USB is everywhere and easily available.
There is however a wide range of USB implementations in hardware that
create the need for many, chip specific, drivers.
The advantage/drawback is the voltage supplied with the connection.
This is intended to provide power to light loads on the outboard end.
It can also be a isolation drawback if it is not properly handled when
the outboard device needs more power than a small cable and the USB
motherboard power supply can provide.
And then there are the designed in timing windows that have to be
overcome. SWP's recent post demonstrated ethernet's inherent advantage
in this respect. It was not designed to be the servant of an operating
system.
Rayh

[Ray Henry]

Hi Tom

You bet it's time to study the use of serial communication systems in
the EMC. Thanks for the interesting links.

Rayh

Post by Thomas Formella
Hi Ray,
thanks a lot for the explanation. It was not my intention to designate USB as
the superior bus for industrial realtime applications. I just wanted to point
out, that there's some (Open Source) research work done already...
BTW: There's an interesting "Feature Comparison Table for Servo Communications
http://sercos.com/tech_info/popup/comparison_table.htm
Though, an comparison table on the SERCOS webpage is likely to be subjective,
maybe FireWire (IEEE-1394) is an alternative to RT-NET ?
http://rtfirewire.dynamized.com/
It's a research work of the 'University of Twente, the Netherlands' and the
word 'aims' applies analogously to this project also...
Anyway, be it USB, Ethernet, SERCOS or FireWire: A *digital* interface
EMC2<>drives would be *very* interesting in my opinion...
Thomas

Post by Ray Henry
Hi Thomas
I believe the critical word here is "aims." I am in agreement that
there is at least one advantage/drawback and at least one perceived
advantage to a USB enabled system.
The perceived advantage is that USB is everywhere and easily available.
There is however a wide range of USB implementations in hardware that
create the need for many, chip specific, drivers.
The advantage/drawback is the voltage supplied with the connection.
This is intended to provide power to light loads on the outboard end.
It can also be a isolation drawback if it is not properly handled when
the outboard device needs more power than a small cable and the USB
motherboard power supply can provide.
And then there are the designed in timing windows that have to be
overcome. SWP's recent post demonstrated ethernet's inherent advantage
in this respect. It was not designed to be the servant of an operating
system.
Rayh

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[Eric H. Johnson]

Jon, Chris,

The basic process I am trying to achieve from an XYZ configuration involves
three passes of the same pattern, a cut pass, a glue pass, and a pass for
the activating agent for the glue. Ideally I was hoping to achieve it with a
single G-Code file, rather than having to create three files for each
pattern, where they only differ by the tool selected, feed rate, and X, Y
and Z offsets to the respective fixtures (tool selection and feed rate are
easily set through the UI).

Further complicating matters is that while the two glue heads are
effectively each a single tool (nothing replaceable), I also have a spindle
and laser. The spindle of course allows for different tools, while the laser
can take different optics, which effectively work out to the same thing, as
each optic will have its own focal length and spot size (diameter).

So I am looking for some way to implement XYZ fixture offsets on top of tool
length and diameter, while maintaining the ability to have multiple work
areas.

I had asked before about writing directly to variables from a user interface
for example, such as the G54-G59 variables, but it did not sound like that
was possible. Additionally I could modify the var file directly, but I
believe that is only read once at initialization.

Is there any thought to more generically doing fixture offsetting, where for
instance lathes would be one permutation, and multiple tool heads another?

Another thought I had, and staying consistent with the HAL architecture, was
making "defined" variables available as ordinary HAL pins, which could be
assigned signals and parameters and otherwise manipulated like any other
pins.

Regards,
Eric

Post by Jon Elson
The G54 through G59 are WORK offsets. The tool table has
diameter and length offsets for the TOOLS, and these are
activated by "calling" the tool and activating either cutter
radius compensation (G41 and G42) or tool length offset (G43).
G43 always adjusts the Z axis, only, and may be more
appropriate when different tools are changed into the same
spindle. The G54 through G59 are supposed to be used for as
offsets to multiple workpieces or fixtures on the machine
table, but I don't see how that is really different from an
offset between different tools on the head, other than the
signs being reversed. So, if an offset to the right of the
workpiece zero offset would have a + X coordinate, then a
tool that was to the right of the "home" tool would need a
MINUS X offset. This would move the work table to the right
(-X) to be under the new tool.
As far as I know, the G54-G59 offsets accept XYZ values.
As the tool table works now (or as of a few weeks ago,
anyway), it does NOT have X and Y offsets associated with
each tool. At least X offsets are needed for lathe work, so
there are plans to add this.

[Chris Radek]

Post by Eric H. Johnson
Jon, Chris,
The basic process I am trying to achieve from an XYZ configuration involves
three passes of the same pattern, a cut pass, a glue pass, and a pass for
the activating agent for the glue. Ideally I was hoping to achieve it with a
single G-Code file, rather than having to create three files for each
pattern, where they only differ by the tool selected, feed rate, and X, Y
and Z offsets to the respective fixtures (tool selection and feed rate are
easily set through the UI).

Maybe you could put most of the program in a subroutine, and call it
several times after manipulating the offsets, either using G5x or G92,
and the loaded tool.

[Ray Henry]

Post by Chris Radek

Post by Eric H. Johnson
Jon, Chris,
The basic process I am trying to achieve from an XYZ configuration involves
three passes of the same pattern, a cut pass, a glue pass, and a pass for
the activating agent for the glue. Ideally I was hoping to achieve it with a
single G-Code file, rather than having to create three files for each
pattern, where they only differ by the tool selected, feed rate, and X, Y
and Z offsets to the respective fixtures (tool selection and feed rate are
easily set through the UI).

Maybe you could put most of the program in a subroutine, and call it
several times after manipulating the offsets, either using G5x or G92,
and the loaded tool.

Chris's suggestion is the way I'd approach the problem today.

In the old days of cut and paste we would have written the geometry as
offsets from numbered variables (example #1000) and made three copies of
it. A few lines added between each copy would have been written to set
the cutting variables to the specific location, tool, feedrate, and
such.

Rayh

[Chris Radek]

Post by Eric H. Johnson
I had asked before about writing directly to variables from a user interface
for example, such as the G54-G59 variables, but it did not sound like that
was possible. Additionally I could modify the var file directly, but I
believe that is only read once at initialization.

I am pretty sure you don't want to mess with the var file directly -
it is written and read at various times (depending which GUI you use I
think, I don't know all the details without study).

[Eric H. Johnson]

Chris,

Post by Chris Radek
I am pretty sure you don't want to mess with the var file
directly - it is written and read at various times (depending
which GUI you use I think, I don't know all the details
without study).

[Ray Henry]

Hi Eric

On Tue, 2006-08-15 at 11:06 -0400, Eric H. Johnson wrote:
<s>

Further complicating matters is that one has effectively an infinite number
of tool lengths for the laser (where G41-43 come in). Because while there
may only be a couple different sets of optics (100mm, 200mm, etc.), one
often wishes to "lie" to the CNC about the actual tool length and diameter.
This can be because one wants the focal point to be at the top, middle or
bottom of the material, because one wants to intentionally defocus the optic
to get a bigger spot size, etc.

The tool length offsets do not follow the tool number. They are set
using hxx within the g-code. You could set quite a wide range of
lengths for the laser in a tool table file and simply apply the one you
want for the specific cut.

Rayh

[Daniel Scheeren]

Dear EMC2 Experts

First I've to say that my english isn't perfect, so, if there is any
mistake, I'm sorry.
Before all, thanks for all these great brain that work together
building a so good software.
I also have searching for X,Y and Z offset for multi tools heads.
Several Italian woodworking machines have a spindel with automatic or
manual tool change and this same machine have other (s) heads for
drill work, sometimes forming a L or T profile. These heads have
several (5-10) drill bits 32mm apart with different diameters and tool
length. Some heads are parallel the X axis and others are parallel to
Y axis. All bits in each head is spinning together but only the
selected (s) go down by a pneumatic piston when is necessary drill a
hole. The total tool number can be 30 or more.
The only solution for these problem is have X,Y and Z offset for each bit.
There are some machines that have the control board burned and is very
difficult find the same board to replace. We are looking for a way for
use EMC2 to retrofit it but I think it is impossible if this X,Y and Z
offset is not working.
Mach3 have these X,Y and Z offset for each tool working yet, but
really I think EMC2 is better and I like it, but...
I will start learn C rigth now but I can't help in this yet.
Just my 2 cents...

Thanks

Daniel

Message: 5
Date: Tue, 15 Aug 2006 08:56:42 -0500
Subject: Re: [Emc-users] Tool / fixture offsets
To: "Enhanced Machine Controller (EMC)"
Content-Type: text/plain; charset=us-ascii

Post by Eric H. Johnson
Jon, Chris,
The basic process I am trying to achieve from an XYZ configuration involves
three passes of the same pattern, a cut pass, a glue pass, and a pass for
the activating agent for the glue. Ideally I was hoping to achieve it with a
single G-Code file, rather than having to create three files for each
pattern, where they only differ by the tool selected, feed rate, and X, Y
and Z offsets to the respective fixtures (tool selection and feed rate are
easily set through the UI).

Maybe you could put most of the program in a subroutine, and call it
several times after manipulating the offsets, either using G5x or G92,
and the loaded tool.
------------------------------
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
------------------------------
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
End of Emc-users Digest, Vol 4, Issue 31
****************************************

[Eric H. Johnson]

Ray,

Post by Ray Henry
The tool length offsets do not follow the tool number. They
are set using hxx within the g-code. You could set quite a
wide range of lengths for the laser in a tool table file and
simply apply the one you want for the specific cut.

Yes, I understand, but at this point my intent was to implement it through
MDI commands. That way I can calculate the offset rather than have some very
large number of tools to choose from. Often the user does not know the exact
setting they want due to any number of factors including variations in the
material itself, temperature and humidity, assist gas, etc. so they will run
a few tests against the material to get the optimal effect, then use that
setting for the actual run.

Regards,
Eric

[Ray Henry]

Got it, Eric but I don't see the need to change the underlying EMC code
to achieve what you are thinking. BTW Hxx is a perfectly good MDI
code.

Why not compute the entire offset set in your HMI front end and set
variables used with axis names. Sometime back I wrote a chapter for the
user handbook about using variables both during a run and saved between
runs. I see that it did not make the cut for the current EMC2 user
handbook but let me quote a bit of it.

1.3 Changing Variable Values

The variable assignment operator allows you to change
the value of a variable while a gcode program is
running. Any reference to a variable name followed by
an equals sign and a number or an expression in
brackets [ ] will assign that number to the named variable.

#1002 = [#1000 + #1001]

In the case of the previous line, #1002 takes on the
value of the sum of two other variables. Variables can
be assigned any values that can be computed within a program.

One interesting case of assignment comes from the fact
that you can assign a variable it's own value so
incrementing is permitted by the interpreter.

#1000 = [#1000 + 1]

If you increment or change a variable while a program
is running it will hold its new value for the next run
of the same program. It will continue to hold the last
value when you start a different program.

1.4 Writing blocks using variables

Right about now, the conventional program code writer
will realize that it is a bit easier to just write the
real numbered code than it is to write the variable
code. It is also easier to read and make sense of real
numbered code as the following two lines illustrate.

Hard code T55 M6 G43 H55 G55 X55 A55

Variable code T#1000 M6 G43 H#1000 G#1000 X#1000 A#1000

And real numbered code will take less time to write if
you want to use that code or those numeric values only
one time. The real value of code written with variables
becomes obvious if you want to re use code for
different sized parts, paste in the same code several
times, or when using different setups and tools.

Variables can also be of value where a location is
repeated many times during a program. Rather than
typing (x21.1345) in a dozen locations in a program you
can assign that value to a variable at the top of your
program and reference it wherever you need to within.
Then if a program wide change needs to be made to that
value it can be done once and all references will shift
to the new value.

Under any of these conditions variable programming
becomes much more efficient than repeating or editing
all those lines of code with the correct values.

Hope this helps

Rayh

Post by Eric H. Johnson
Ray,

Post by Ray Henry
The tool length offsets do not follow the tool number. They
are set using hxx within the g-code. You could set quite a
wide range of lengths for the laser in a tool table file and
simply apply the one you want for the specific cut.

Yes, I understand, but at this point my intent was to implement it through
MDI commands. That way I can calculate the offset rather than have some very
large number of tools to choose from. Often the user does not know the exact
setting they want due to any number of factors including variations in the
material itself, temperature and humidity, assist gas, etc. so they will run
a few tests against the material to get the optimal effect, then use that
setting for the actual run.
Regards,
Eric
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Eric H. Johnson]

I am trying to generate a a PWM signal with the m5i20 board. Is there
anything beyond the following which I need to do?

newsig pwm1 float
linksp pwm1 => m5i20.0.dac-00-value

newsig pwm1enable bit
linksp pwm1enable => m5i20.0.dac-00-enable

sets pwm1enable TRUE

sets pwm1 5.0 # For example

I am not seeing anything on the scope (Pin 15 on P2 for PWM0), no matter
what value I set for pwm1 (0.0 - 1.0 or 0.0 to 10.0, not quite sure about
the default scale). Is there something else I need to enable to get just a
PWM duty cycle from this board?

I do not need the PWM signal for motion control, I just need to be able to
directly set the duty cycle for the PWM.

Regards,
Eric

[Peter C. Wallace]

Post by Eric H. Johnson
I am trying to generate a a PWM signal with the m5i20 board. Is there
anything beyond the following which I need to do?
newsig pwm1 float
linksp pwm1 => m5i20.0.dac-00-value
newsig pwm1enable bit
linksp pwm1enable => m5i20.0.dac-00-enable
sets pwm1enable TRUE
sets pwm1 5.0 # For example
I am not seeing anything on the scope (Pin 15 on P2 for PWM0), no matter
what value I set for pwm1 (0.0 - 1.0 or 0.0 to 10.0, not quite sure about
the default scale). Is there something else I need to enable to get just a
PWM duty cycle from this board?
I do not need the PWM signal for motion control, I just need to be able to
directly set the duty cycle for the PWM.
Regards,
Eric

Theres a global enable in the hardware, not sure where thats turned on. That
may be the problem (dont know how thats done in the HAL)


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

[Anders Wallin]

Post by Eric H. Johnson
I am trying to generate a a PWM signal with the m5i20 board. Is there
anything beyond the following which I need to do?

try my experimental m5i20 test panel:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?M5i20_Halvcp_Test_Panel

or, look directly at the HAL
http://wiki.linuxcnc.org/uploads/iotest.hal

Post by Eric H. Johnson
newsig pwm1 float
linksp pwm1 => m5i20.0.dac-00-value
newsig pwm1enable bit
linksp pwm1enable => m5i20.0.dac-00-enable
sets pwm1enable TRUE
sets pwm1 5.0 # For example

you are missing a call to the function m5i20.0.dac-write

in my file I have a thread called 'tt', so I add the dac-write function
to the thread:
addf m5i20.0.dac-write tt

Also note that when you load the driver you specify a dacRate parameter
which should determine the pwm period.
If you are filtering the pwm to analog you should try the interlaced
mode(it should be on by default I think).

Anders

[Eric H. Johnson]

Anders,

Post by Anders Wallin
you are missing a call to the function m5i20.0.dac-write
in my file I have a thread called 'tt', so I add the
addf m5i20.0.dac-write tt
Also note that when you load the driver you specify a dacRate
parameter which should determine the pwm period.
If you are filtering the pwm to analog you should try the
interlaced mode(it should be on by default I think).

That is what I forgot. I moved all of the driver loading stuff from
m5i20_io.hal, so all my DIO was working, but I missed that which is loaded
in m5i20_motion.hal.

What parameter ultimately gets passed to the m5i20 driver to set the PWM
frequency? I tried:
loadrt hal_m5i20 period=200000

But it seems no matter what parameter I pass for period, I don't seem to be
able to change the frequency from the default, which seems to be 25khz.
Period is the task period I take it, rather than the PWM frequency. My
acceptable range is 5khz to 25khz, but I would prefer to set the frequency
to 5khz.

Post by Anders Wallin
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?M5i20_Halvcp_Test_Panel
or, look directly at the HAL
http://wiki.linuxcnc.org/uploads/iotest.hal

I did look at it, and in fact wrote my own simple I/O checkout program,
since I am using both the vti and m5i20 drivers. I did my whole I/O checkout
that way, and the only thing that was not working was the PWM output (which
is the only signal I am using off of the P2 connector).

Thanks,
Eric

[Anders Wallin]

Post by Eric H. Johnson
What parameter ultimately gets passed to the m5i20 driver to set the PWM
loadrt hal_m5i20 period=200000

the maximum might be 32 kHz, I don't know what the minimum is...

make sure you have the interlace mode OFF, otherwise the period= setting
will have little or no effect on the waveforms you see.


AW

[Peter C. Wallace]

Post by Anders Wallin

Post by Eric H. Johnson
What parameter ultimately gets passed to the m5i20 driver to set the PWM
loadrt hal_m5i20 period=200000

the maximum might be 32 kHz, I don't know what the minimum is...
make sure you have the interlace mode OFF, otherwise the period= setting
will have little or no effect on the waveforms you see.
AW

Because PWM is 10 bits, maximum is around 32 KHz (= 33 MHz PCI Clk /1024)

PWM rate is determined by 16 bit DDS (phase accumulator) so PWM rate is:

33 MHz/1024 * PhaseAccVal/65536

minumum is around .5 Hz (33 Mhz /2^16)/2^10

Not sure where these are in the HAL

Post by Anders Wallin
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Emc-users mailing list
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.

[Eric H. Johnson]

Anders,

I have interlace mode off and I am seeing the pulse width change in
proportion to the values I send, but the frequency does not seem to be
affected by the value specified with period. I have tried values from 5000
to 5000000, but the frequency remains the same.

What are the units for period, Hz or nanoseconds? By the comment in one of
the config files it looks to be the latter because it sets period to 1000000
and says that is 1ms.

Regards,
Eric

Post by Anders Wallin
the maximum might be 32 kHz, I don't know what the minimum is...
make sure you have the interlace mode OFF, otherwise the
period= setting will have little or no effect on the
waveforms you see.

[Eric H. Johnson]

Hi all,

My Z axis needs to home to the max limit (i.e. up), but once it does, set
that position to a value such as 8.0". Thus having a range of 8.0 to 0.0,
and decreasing as the head moves down. The home itself and the count
direction are working fine, I am just not able to set the current position
to a non-zero value once the home completes. I thought this was what "Home =
X Y Z" in the Traj section of the ini file was supposed to do, but that did
not seem to have any effect.

I also tried home_offset in the section for the individual axis, but that
moves it to a position following the completion of a home.

Regards,
Eric

[j***@att.net]

-------------- Original message ----------------------

Post by Eric H. Johnson
Hi all,
My Z axis needs to home to the max limit (i.e. up), but once it does, set
that position to a value such as 8.0". Thus having a range of 8.0 to 0.0,
and decreasing as the head moves down. The home itself and the count
direction are working fine, I am just not able to set the current position
to a non-zero value once the home completes. I thought this was what "Home =
X Y Z" in the Traj section of the ini file was supposed to do, but that did
not seem to have any effect.
I also tried home_offset in the section for the individual axis, but that
moves it to a position following the completion of a home.

I think you need to set both HOME_OFFSET and HOME (in the [AXIS_2]
section) to 8.0. Setting HOME_OFFSET to 8.0 says "the home switch
is at 8.0", and setting HOME to 8.0 says "after you find the switch,
go to 8.0". With both set the same, it won't move after finding the
switch.

Actually if you are homing off a limit switch, you probably want to set
HOME_OFFSET to something like 8.1 and leave HOME at 8.0. That way, after
homing it will move off the limit switch. Then you can set your soft
limits to 0.0 and 8.0 and they will keep you from hitting the hard limit.

Regards,

John Kasunich

[Eric H. Johnson]

John,

Thanks, I think I have it now, although it still seems a little odd. If I
set home and home_offset to 8.0, it does in fact home and set the current
position to 8.0, and as you indicate, is sitting on the max limit. However,
if I set home_offset to 7.8, it moves 2 tenths past the limit, rather than
moving off the limit in the direction of the min limit. If I set home_offset
to 8.2, then it goes where I intended, and sets the current position
appropriately.

Regards,
Eric

Post by j***@att.net
I think you need to set both HOME_OFFSET and HOME (in the [AXIS_2]
section) to 8.0. Setting HOME_OFFSET to 8.0 says "the home
switch is at 8.0", and setting HOME to 8.0 says "after you
find the switch, go to 8.0". With both set the same, it
won't move after finding the switch.
Actually if you are homing off a limit switch, you probably
want to set HOME_OFFSET to something like 8.1 and leave HOME
at 8.0. That way, after homing it will move off the limit
switch. Then you can set your soft limits to 0.0 and 8.0 and
they will keep you from hitting the hard limit.

[j***@att.net]

-------------- Original message ----------------------

Post by Eric H. Johnson
John,
Thanks, I think I have it now, although it still seems a little odd. If I
set home and home_offset to 8.0, it does in fact home and set the current
position to 8.0, and as you indicate, is sitting on the max limit. However,
if I set home_offset to 7.8, it moves 2 tenths past the limit, rather than
moving off the limit in the direction of the min limit.

The parameter names aren't very informative, but that is exactly what it is
supposed to do.

Think of "home_offset" as "coordinate of home switch", and "home" as "where
to go when done homing". If coordinate of home switch is 7.8, and where to
go when done is 8.0, then it will indeed move 0.2" beyond the switch when
it finishes homing.

Post by Eric H. Johnson
If I set home_offset to 8.2, then it goes where I intended, and sets the
current position appropriately.

Glad you have it doing what you want.

Regards,

John Kasunich