[Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello,
One of the things that troubles me is that I am not seeing much work to
make the Linuxcnc project feel like an embedded system.
To me, it just seems quite unprofessional to have a desktop looking
environment that is running in a milling machine. Is there some reason that
someone (other than me) has not worked up a distro that is purpose built to
run EMC similar to the way the the folks at MyData made their stuff work?
Is there some reason that the user interfaces do not have the features of
an embedded system included such as a button to shutdown or reboot the
system, or even an embedded mode that makes them take over the whole screen?
For example, Gmoccapy has a feature in the settings to take over the whole
screen, but it is an option that you can get to via the GUI. For this to be
realistic, this option needs to be in a configuration file that you can not
get to via the GUI.
Thank you,
-Neil-
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello Dave,
Thank you for the input. I am not aware of many commercial grade machines
that have "apps" to create G-code. I have carefully reviewed many
controllers from many companies such as FANUC, Haas, Toshiba, DynaPath,
DMG, and others, none of the controllers I have looked at use "apps", nor
do they have anything to create G-code. Many have a "conversational"
interface that is really intended to be used in place of G-code, but these
machines I find extremely difficult to program for anything other than the
most basic part. Also, I find it extremely difficult to do anything to
create code directly on the machine. In the shop, it is normally noisy and
distracting to be concentrating on editing code on a machine, that is
something I do back in my office. Also, I find it completely shocking how
many pictures I see of machines with PC style keyboards and mice attached.
In my shop, that would be filled with dirt, coolant and chips in the first
30 seconds! All of my machines use a tempered glass acoustic touch screen,
and I have a minimum of hard buttons, all of which are water tight. I try
to limit my interaction with the machine to selecting which part program I
am going to run and general setup of the machine. Also from my tests, it is
not reasonable to setup a machine interface in a location where it is both
easy to sit at like you would use a desktop computer and make it so that it
is comfortable for the machine operator to use. The two tasks just are not
compatible.
Can you please explain under what situations that a "user" would want to do
something like run "apps" on a machine? (I am not seeing this from your
viewpoint for some reason.) Also, can you explain what you mean by "user"
are you talking about the person that operates the machine, or the person
that does the part programming?
Also, I would like to point out that Gmoccapy has tabs that things can be
embedded in. I have found it very handy to embed a calculator in one tab,
but I have not (yet) found use for anything else.
-Neil-


On Fri, Dec 25, 2015 at 1:22 AM, Dave Caroline 
wrote:

> Are you forgetting the other apps people use on their machines to
> create the gcode.
> Not something I really want as a user
>
> Dave Caroline
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello Dave,
I simply can not afford to have a machine idle while I use an "app" on it.
If it is not running, it is not making money. If I am editing a program,
someone else is using the machine to make things. There are plenty of small
shops and "one man bands" that use a desktop computer for CAD/CAM, and
editing, then they upload the program to a machine to make the part. I, for
one do not like to be sitting in the middle of a workshop in an awkward
position to see a small display mounted to the side of a 5,000 pound
machine to write G-code, when I can do it from the comfort of my desk in my
office.
Also, we are right back to if I am running something like an "app" on the
machine, a keyboard and such is required, and I am not about to put a
keyboard on a machine, the coolant and chips would kill it before there is
time to use it for anything.
I can understand why some hobbyists would want to use the computer on their
machine to do other things than run the machine, but that is not the scope
I am talking about here. Most of the people I have running machines, just
want to load up the fixtures with stock, push the "go" button, and take a
part out. The only time that they end up doing anything else is when they
break something, or change to another part.
By adding "apps" to the machine, it is detracting from its simplicity of
use to the machine operator. More moving parts, more to break.
The big problem I see with the Linuxcnc project is that its maturation into
the real world is limited (more like blocked) by steering from hobbyists.
Under the hood Linuxcnc is a marvel of fantastic software engineering that
is far superior to many professional controllers, and if it was treated as
such would give the mega bucks commercial controllers a big challenge in
the marketplace. All it is going to take is a "big" machine company to
adopt it... This will NOT happen in its current state because it is still
dressed like a toy. There is nothing wrong with this either. If you look at
my original post, what I am getting at is that Linuxcnc needs both. It
needs a toy wrapper for hobbyists, and it needs a tool wrapper for people
that want to use it as a tool. What I am saying is that there seems to be a
push for it to be a toy when under the hood it is far better than most
tools. I am wondering why there is not much (any) push from within to make
a tool out of it while not detracting from its ability to be a toy.
-Neil-


On Fri, Dec 25, 2015 at 3:30 AM, Dave Caroline 
wrote:

> My main "app" is an editor I sit on the machine and edit the code to
> make the item, others use things such as dxf2gcode.
>
> I am one of many who are one man bands making stuff in various ways on
> various machines, three of mine are Linuxcnc, the hobbing machine has
> a screen to set up gear cutting, the mill has edited gcode which is
> designed at the same time as the fixture is set up, and a lathe
> usually used in mdi mode.
>
> This kind of flexibility is missing on machines made for "operators".
>
> Dave Caroline
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello Ken,
I get that, I have already done a bunch of programming in this direction,
the plan is to contribute it. The reason that I started this discussion is
that I am wondering if anyone else is already barking up this tree that I
can join forces with.
At the moment, I have adopted Gmoccapy as a starting point. I am wondering
if it would be agreeable with the maintainers of Gmoccapy to add options to
it to make it more like an embedded interface, or if it makes more sense to
fork it.
-Neil-


On Fri, Dec 25, 2015 at 4:34 AM, Kenneth Lerman  wrote:

> The "standard" answer is that if you want it to look more like a commercial
> CNC machine you can do that.
>
> It's simply a matter of programming. 😀
>
> I suggest that you start by defining the requirements. When I added o-words
> and named parameters to the interpreter I started by defining the
> requirements and discussed possible designs on the list and the wiki. That
> generated some useful feedback.
>
> It might be useful to define the requirements even if you are not a
> programmer. Who knows, you might find someone with similar requirements who
> can do the programming.
>
> Regards,
>
> Ken
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello all,
First of all, this is a really fantastic bunch of people here! I can't
think of any other mail list where everyone that has replied so far makes
sense and provides directly useful insight.
I realize that maintaining an embedded OS is not easy, and expensive. I
have been doing this since 1993, and I have focused specifically on the X86
(replaced by the AMD64), and ARM builds.
I have built a board around the Allwell A20 that has the same FPGA as used
on the Mesa 5i24 on the board as well as open drain drivers and input
conditioning and protection. At some point, I might decide to make a box,
and HMI to go with it, but for now it is just a board.
I have also made a number of changes to Gmoccapy to make it embedded
friendly, and so far it is working quite well.
The point is that I am already standing at this doorstep, and I am opening
the discussion as to what the best way is for me to contribute both the
changes to Linuxcnc and the embedded OS, and possibly collect some support
along the way.
-Neil-



On Fri, Dec 25, 2015 at 10:32 AM, Sarah Armstrong <
sarahj.armstron...@gmail.com> wrote:

> I'm Available !
> ( glad this is not an open group Gene ) LOL
> I'd probably have a queue around the block .
>
>
>
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello Sarah,
Much appreciated! I will start by sharing my thoughts and code. But it is
unclear to me which approach is the best for everyone involved.
As I mentioned before, I started with Gmoccapy. The more I think about it,
the more I am thinking that it makes more sense to fork it as opposed to
adding an embedded mode to it. The way I see it is that the embedded and
desktop mods are just too much in conflict even though Gmoccapy seems to
work best of all of the interfaces I have tested. So I think I am going to
start by forking and removing all of the desktop specific things from
Gmoccapy, unless someone has a better approach or suggestions.
Also, what's the deal with the tool editor?! Either I am not understanding
the intent (if this is the case, someone please explain the design intent
to me), or it is horrible. I will explain... There is a checkbox AND a row
selection. You can have one row selected (highlighted) and another row
checked. This is confusing at best, and difficult to use with a touch
screen. Also, when using the on-screen keyboard, I find myself editing a
field and then clicking on the next field which reverts the changes I just
made. I have to force myself to slow down and click 'enter' every time. (I
still find myself looping around and having to re-edit the same cell again
and again because I am doing what I find natural and clicking on the next
cell I want to edit.) I have made numerous changes to this to eliminate the
checkbox, and to save the changes when the focus changes between cells. The
problem is that in the meantime, someone added some tabs and such to the
tool editor, so I need to update it for the changes. Anyone have
suggestions here?
-Neil-


On Fri, Dec 25, 2015 at 12:22 PM, Sarah Armstrong <
sarahj.armstron...@gmail.com> wrote:

> i'm happy to help Neil
>
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello Brian,
At the moment, the interface, and some OS integration are the places that I
feel need the most attention.
The interface needs tools to mount external (USB) devices and manage files
as well as make backups and control the OS (shutdown, reboot...).  Another
very important thing is that there should be some sort of a toolset
database. The flat tool file is a thing of the past. There needs to be a
way of associating part programs with specific sets of tools. Often, when I
setup a new part, I empty the tool changer and reload it with tools for
that job. Later, when I switch back to run more of the previous part, I
have to copy the previous tool file back. While this is easy, it can not be
done with any existing UI, and this is typical of the problems that the
existing UIs have.
At the moment, I see no need for a custom kernel or anything like that, but
it will eventually end up there. We have to start with the lowest hanging
fruit to do the most good in the least time, so starting with the intent to
make an 'embedded' like UI is by far the lowest fruit.
I will setup a public repository with what I have so far.
-Neil-


On Fri, Dec 25, 2015 at 11:47 AM, Brian  wrote:

> I'll throw my hat in the ring for a more embedded, dedicated
> appearing/functioning interface.  I think such an option would make LCNC a
> more viable option for real, commercial application.
>
> This could be anything from a configuration option or GUI, to a full blown
> dedicated kernel or anything in between.
>
> It seems to me that Tormach has already started down this path with Path
> Pilot.  Although I have never actually seen it, from what I hear, it makes
> accessing the desktop and other PC functionality not functional or not
> obvious.
>
> Brian
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello Chris,
Yes, Ubuntu and most others will load up whatever you want on boot, but
that is really not the point. The problem with nearly ANY release out there
is that there is a TON of bloat. Take just the window manager alone, most
of them use OpenGL to do fancy transitions, some window managers have more
than 200,000 lines of code! There are dozens of things that Ubuntu loads
that are not desirable in a system that must be reliable. The idea here is
lean and mean. The more things that are loaded or running, the better the
chances that something will crash or otherwise go wrong. The distro that I
am working with is just under 21 MB total. The entire thing including
Linuxcnc fits in the initrd. That and the Linux kernel fit onto the 32 MB
flash on my ARM board, and it boots to Gmoccapy in less than 10 seconds.
-Neil-



> > I'm pretty sure you can have ubuntu load a program on startup, so
> > besides seeing Ububtu or debian start screen you could have your
> > screen start up directly.
> >
> > Chris M
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

> Can you explain exactly what you mean by embedded?
> i think you mean like a fanuc or tormach  where you turn on the machine and
> that is all you can see.
>
> Yes, along those lines. The point is not so much that as it is
reliability. It has to "just work", and it has to do so for people that do
not know much about linux, or computers.
For example, the system I built has everything in the initrd, so / is
mounted read only. Part programs, parameters, and tool tables are stored in
a small partition that is read-write. I added a button that makes a tarball
from the files on that partition to a raw partition (a backup button).
When the machine is booted, if the partition fails to mount, it is
formatted, and the tarball is restored to it. This way, no matter what disk
corruption may happen, it will always boot, even when the power is yanked
without a proper shutdown.


> > To me, it just seems quite unprofessional to have a desktop looking
> > environment that is running in a milling machine. Is there some reason
> that
> > someone (other than me) has not worked up a distro that is purpose built
> to
> > run EMC similar to the way the the folks at MyData made their stuff work?
>
> Distro work is a fairly painful and personal opinion work.
> Nobody really likes to do it. Nobody is happy with all choices made.
> It's necessary evil.
>

I have been maintaining distros for embedded systems for over 25 years now.
That is what I do. My main product is a distro that runs Asterisk in an
appliance, which I have modified to run Linuxcnc.

>
> > Is there some reason that the user interfaces do not have the features of
> > an embedded system included such as a button to shutdown or reboot the
> > system, or even an embedded mode that makes them take over the whole
> screen?
>
> take over the screen yes - gmoccapy any of gscreen and even AXIS can (with
> a bit of work)
> Shutdown and reboot surely that can be added - you are the first to ask
> about it
> that I know of.
>
> Without these features, it is incomplete and it must work in a desktop
environment. This is the most important thing that stands in the way of
Linuxcnc being taken seriously by machine builders. It is really the
defining difference between a commercial system, and a hobby system.



> > For example, Gmoccapy has a feature in the settings to take over the
> whole
> > screen, but it is an option that you can get to via the GUI. For this to
> be
> > realistic, this option needs to be in a configuration file that you can
> not
> > get to via the GUI.
>
> Gmoccapy and gscreen Industrial have that option page hidden behind a
> security
> code. It would be easy to make it not pop the security code dialog.
>

I know about that, but that is not the point. The interface needs to be
purpose built to take over the system. I will use MyData TpSys as my
example here.
-Neil-



>
> Chris M
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello Chris,
The reference to MyData is a pick and place machine that is used to
assemble circuit boards. Check out
https://www.youtube.com/watch?v=56hQ0oBJ4xk Those machines are about the
best example I can think of for a well done application of Linux and
robotics. TpSys (the software that runs the machine) has many similarities
to Linuxcnc. In addition, TpSys has many features that I would like to see
in Linuxcnc:

1) Optical alignment. It uses a camera to look for fiducial marks on the
circuit board to align, scale and rotate the coordinate system.  (With
Linuxcnc, this can be done with a touch probe.)  (It also uses a camera to
examine each part that it is about to place on the board for bent pins, and
alignment. It can reject parts that do not match the programed physical
limits.)

2) It measures board height (and Z alignment), tool height, component
height, travel limits and collisions by force feedback. I would like to see
features like this in Linuxcnc as well, however this is clearly not suited
to many machines, but I can think of a few situations where force feedback
would really help. For example, I have ran my circuit board drill with
EMC/Linuxcnc for over 10 years now. While it works well, commercial circuit
board drilling machines use force feedback to determine drill speed, and
tool condition. This would be a huge help here.

3) It is a great example of a well done integration and embedding job.
Everything it done through the GUI. Setup, programming, backups, software
upgrades, configuration, diagnostics, calibration, you name it, the GUI
does it all. Sure, you can still hit f1 to get to a login
prompt, but under normal usage, and maintenance, there is no reason to do
so.

4)  There are directories that programs are put in to do various
maintenance tasks. You can add anything you want to the directory, and the
system runs it with " --info" when the GUI loads, and the
STDOUT is used to build the menu entry and help screens in the GUI. (Most
of these programs are perl scripts, but they can really be anything.)
Gmoccapy does something similar with NC programs, so this is a fine start,
all it needs is to not involve the configuration file, and it needs another
directory to place scripts.

5) This is the kicker that is missing in most commercial grade CNC
machines. It has a database to track jobs. It keeps track of how many of
each part is made, which components went on which board. (It can tell you
that in spot R5, a resistor of 5.51 ohms, yes it tests each component it
installs, from reel serial number 1234, 20th part from the start of the
reel was installed on board 63 at 11:57:22.10 on 11-2-2015) This also
allows you to do partial assembly of boards, and re-load the board later to
finish it. Where this crosses over to the machining world is a database to
track part programs and associate tool databases with part programs, when
they were last used, and at which point tools were replaced. This should
also track part serial numbers and a timestamp. Also, it would be really
handy to associate machine logs with the part serial number, and which
machine operator was running the machine. (TpSys uses a password that is
unique for each operator, there is no login.)

Asterisk is a phone switch. http://asterisk.org I have been making Asterisk
appliances for 12 years now. Many of them run far in excess of 5 years
between reboots. They are mostly used in office environments with 10-500
phones. They are configured by a web browser, there is no console. I
mentioned this because it is an example of a Linux based appliance that has
to "just work".

As far as a distro goes, I already have a number of my NC machines running
with a custom distro, it is already done. I am happy to make it available.
Everything that is distro specific that I created is GPL.

I have already added a menu to Gmoccapy to handle system tasks like reboot
and shutdown. I replace the exit button in the lower corner with a button
that is only active when the machine is in "off" state, that loads a row of
buttons into the bottom row that handle system tasks.

I realize that Linuxcnc has no official direction. It is like many open
source things I have worked with, it exists due to the needs of many which
are similar but not the same. This is why since I have been posting about
this subject here, I have decided to make a fork of a UI instead of modify
and existing one. This way, the goals I have discussed about moving to an
embedded platform are for the most part isolated to the GUI, and have very
little impact on the core. However, other features that have nothing to do
with being embedded or not are tied into the core. Automatic coordinate
system scaling and rotation for example. These things are totally
unrelated, and are outside of my current project, but it would be fantastic
if someone were to look at this.

-Neil-


> Then it seems you are the perfect person to to build such a distro.
> I was telling _why_  (at least one reason) we do

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello EBo,
I have never intended to be insulting or demanding in any of my posts. If
it appears that way, I apologize. If you would like to point out what seems
that way to you, I will re-phrase it so that it is not that way, and I will
avoid using such wording in the future.
I am working on posting all of my code on my website, I expect to have it
up in a day or so. I am also asking the developers of Linuxcnc for advice
as to what the best way to make the code available and contribute the
changes I have made.
-Neil-


> I would ask you though to not be insulting and demeaning in your
> comments.  If you are then I, and probably others, will likely stop
> reading what you write and it will end up in another big kerfuffle.  You
> have what appears on the face of it to have some good ideas.  If you
> want us to take them seriously and maybe even help, then show us the
> code, and don't insult us for decisions made a decade before most of us
> even got involved with LCNC.
>
>EBo --
>
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello EBo,
The A20 board has a 3 volt lithium battery on it that will keep the CPU and
memory alive for about 20 minutes. The software is setup to shutdown if
power is absent for more than 3 minutes. This is really not required
because the / filesystem is read only, and the read-write filesystem is
XFS.
My X86-64 distro takes considerably longer to boot. Both BIOS and the PC
hardware scan slow things down considerably, which adds in excess of 30
seconds more to the boot time.
Shutdown is about the same on both platforms, at about 4 seconds.

While LOC is a concern (the more parts, the more chances of failure), that
is not the driving point. The driving point is bloat. Using a desktop OS to
drive a machine is just a bad idea, no matter how you slice it. When you
are controlling a machine, reliability is everything. The problem with a
desktop OS is that there are many factors that are out of control,
especially things like web browsers. There is almost no control of how many
CPU cycles, HD access, and memory that a browser uses. Also, they use many
features of the graphics system, so if there is a bug in the graphics
system, a web browser usually brings it out and in some cases can take out
X11.  Experience has demonstrated that if you eliminate X11, you eliminate
about 90% of the things that randomly crash a machine. That is one major
advantage of working with Qt and GTK, you can run the applications straight
to the Linux framebuffer and bypass X11 entirely. It is absolutely amazing
how more reliable things become when you get rid of all of the bloat that
X11 and the window manager add, not to mention all of the things that are
not in the path, like a desktop, launcher, file indexers, session servers
(session servers are the biggest breaking point of most desktop systems)...
-Neil-



>
>
> If you can get it to boot in that amount of time, I would also ask how
> much time does it take to properly shutdown.  At that point I would set
> up a small UPS which has at least 3x the power required to do a proper
> shutdown (which I am assuming would be something on the order of 10
> seconds, or 30s for a safety margin, and can probably be done with some
> capacitors).  Then if someone removed the power on the fly it does not
> matter.
>
> Also, if you are deeply concerned about LOC, then take a look at the
> Plan9 OS and its derivatives like Inferno and Plan B.  The entire code
> base for Plan 9 is ~80,000 LOC for the entire OS.  Using the 9P protocol
> and similar you should be able to drop the an expected 50% off of the
> LOC for your chosen interface and stuff it even further down the eeprom
> hole.
>
>EBo --
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello EBo,
My comments are in-line below...

On Sat, Dec 26, 2015 at 3:15 PM, EBo  wrote:

> Dear Neil,
>
> No worrier here.  I was jut really trying to gauge if you were trying
> to be so or if I was just being overly sensitive.  I think it was the
> latter, so think noting of it.  The folks here put a lot of sweat,
> tears, and occasionally even a little blood into their work.  There is
> also a bit of history with at least 4 different companies that I know of
> engaging us in one way or another over the decades, and most of the
> interactions ended with less than pleasant memories so there are
> sensitive places here and there.  Like I said, it was not intentional so
> no worries.
>

I understand, it is also hard to judge the intent when you are typing
instead of talking, so much inflection is lost. Also, I am guilty of going
straight to the point, so that is sometimes abrupt. What I will say is that
the Linuxcnc project and the associated people are a really fantastic
thing! HAL is a true masterpiece of work, it is far superior to any other
approach I have ever seen. And behind great work like that are great
people, otherwise it would not be possible, so thank you to everyone that
contributed to this project!


>
> You have a nice vision of things.  It is different than many of us, and
> if you are willing to roll up your sleeves and help (which it sounds
> like you are) then we can either find a way to integrate it or to help
> with a fork.  Even that is likely to cause some grumbling because
> inevitably someone reaches out for help from us on one of these
> off-shoots, and it ends up draining time and resources we would
> otherwise use to focus on our own projects.
>
> When I mentioned fork, I was only talking about forking Gmoccapy and
closely related things within the same project. (Not forking Linuxcnc.) All
I am really pushing for is a new UI that works properly in an embedded
system, that is optional to use like any other UI.
Any changes made to anything outside of the UI would be done in a way that
it does not disturb anything existing.
Basically, I was thinking that I would copy the gmoccapy directory to
another name, and move in a different direction.
I am stuck on names, so far, I have called it "embedded". If anyone has any
objections to this, or a better name, I am all ears.



> One of the key things we need to discuss is if your approach to things
> (like different OS, new interfaces, etc.) will integrate into the
> existing infrastructure, or if you are going to try to convince us that
> something else is better.  We are all open to new things, but for us to
> uproot any underlying assumptions will take a lot of effort on your part
> to get the ball rolling and to convince us of any benefits.
>

The idea here is to be as non disruptive as possible. The whole idea of
running it under my distro is completely optional. By the way, my distro is
called LinuxInside. I normally do not release it as a general purpose OS. I
include it on appliances, and the source and packages are available from
the websites of the products.

-Neil-


>
> I look forward to looking at the code.  I hope I will have time to look
> into when it comes along, and I wish you the best of luck with your
> project.
>
>EBo --
>
> On Dec 26 2015 11:51 AM, Neil Whelchel wrote:
> > Hello EBo,
> > I have never intended to be insulting or demanding in any of my
> > posts. If
> > it appears that way, I apologize. If you would like to point out what
> > seems
> > that way to you, I will re-phrase it so that it is not that way, and
> > I will
> > avoid using such wording in the future.
> > I am working on posting all of my code on my website, I expect to
> > have it
> > up in a day or so. I am also asking the developers of Linuxcnc for
> > advice
> > as to what the best way to make the code available and contribute the
> > changes I have made.
> > -Neil-
> >
> >
> >> I would ask you though to not be insulting and demeaning in your
> >> comments.  If you are then I, and probably others, will likely stop
> >> reading what you write and it will end up in another big kerfuffle.
> >> You
> >> have what appears on the face of it to have some good ideas.  If you
> >> want us to take them seriously and maybe even help, then show us the
> >> code, and don't insult us for decisions made a decade before most of
> >> us
> >> even got involved with LCNC.
> >>
> >>EBo --
> >>
> >>
> >>
> >>
> >>
> --
> >> ___
> >> Emc-developer

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello John,
I apologize for sounding that way. The back story is that I have been using
Linuxcnc/EMC for many years in a production environment. Actually, all of
my shop equipment runs Linux, so I know (at least in my situation) what
works and what does not. I have been seeing discussions about Linuxcnc in
other places, in particular CNC Cookbook, and the number one issue is that
it behaves more like a hobby tool, than a tool that you would trust to run
your shop floor. I am forced to agree with this impression, but the facts
are different, Linuxcnc is extremely reliable and capable of running nearly
any machine, but it requires more than an integration job to do so. This is
where I was thinking I could be of use to the project. I have been using
Linuxcnc for years, I thought I might get on the other end and contribute
back.

After reading my posts, I see the comment I made about the tool editor
looks bad. To clarify, I was asking for someone to explain the rationale
behind the way that it works if I was not understanding it properly. Also,
I was pointing out the issues I was experiencing using it possibly because
of my lack of understanding.

Also, I might point out that the start of this conversation, I was asking
if anyone else was working on heading in the embedded direction so I could
share notes and assist them directly. If there is nobody doing this, I
would be happy to start contributing here.
-Neil-


On Sat, Dec 26, 2015 at 3:32 PM, John Thornton  wrote:

> At first it felt like you were coming across a bit strong and demanding
> but the more you talked you calmed down...
>
> The wiki has good and bad points as does the forum and the mailing list.
> To cover all areas you would need to use all three.
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello EBo,
Yes, it helps. I will look into them. I have used EMC on PC104s in the
past, but the ones I have used are just normal PC platform. They are way
too expensive, and they are sometimes not as reliable as some commodity PC
hardware. I have had better success with the VIA EPIA boards. The
BeagleBone is a good one with plenty of GPIO pins. I have found it awkward
to interface FPGAs to it, so it is mostly limited to running steppers,
though I have one running with an Altera Spartan II FPGA, but by the time I
got it up and running, it ended up looking like a huge hack, so that was
the reason that I built the A20 board.
-Neil-


On Sat, Dec 26, 2015 at 4:36 PM, EBo  wrote:

> On Dec 26 2015 5:20 PM, Neil Whelchel wrote:
> > ...
> >
> > Also, I might point out that the start of this conversation, I was
> > asking
> > if anyone else was working on heading in the embedded direction so I
> > could
> > share notes and assist them directly. If there is nobody doing this,
> > I
> > would be happy to start contributing here.
>
> Yishin Li has an interesting piece of kit that embeds NURBS on and FPGA
> controller.  His new version runs as an RPi cape.  There are others
> which are focusing on small embedded machines as well.  Take a look at
> the blog posts on LCNC on BeagleBone in particular.
>
> Other than that, I have head of some work on PC104 systems.
>
> Hope that helps,
>
>EBo --
>
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello Jon,
It is not a retrofit. MyData has used Linux since about 1993 on all of
their machines, for a short time before that they used Xenix, but the Xenix
versions never worked well. The software is called TpSys, it is a
collection of C, Perl, and bash programs, about 300 of them. The design is
fantastic and well thought out. They are also extremely reliable, and
stable both hardware and software.
Here is a video of someone setting up a machine, this video is one of the
few that allows you to see the UI.
https://www.youtube.com/watch?v=UdJxuux0r28
Here is a video of the machine in action. The red flash that you see is the
up looking camera. It looks at the parts that the 9 vacuum tweezers
(nozzles) are holding as they move past to make a precise measurement of
the locations of the pins on the parts so that it can calculate the
position offset and rotation of the part when it places it on the board.
These machines typically place pins to within 0.0005 inches.
https://www.youtube.com/watch?v=M-aWoHl6pyM
I have extensive experience with these machines, I am happy to answer any
questions that you might have about them, but I am not sure that this is
the right place to have this conversation unless the rest of the Linuxcnc
developers are interested in listening in on this tangent...
But since we are here, I will put in my 2 cents worth.
I have been following the OpenPnP project for some time, and as far as I
can tell, they have some (extremely) good ideas, but they are headed in the
wrong direction. It is not likely ever going to be in a position to be a
good retrofit tool for anything, it will likely only work good on hobby
machines. In the PnP world, there is a totally different focus between
hobby and professional machines. In the machining world, this difference is
much smaller currently, but it is just a matter of time until the machining
world makes the same changes that the PNP world has made 25 years ago, and
at at that time, there will be a huge difference between hobby and
production machines that will make them differ enough that it will not make
any sense to use the same software for both roles. Until this happens,
Linuxcnc is nearly always a huge upgrade in all aspects (with the exception
of the UI) for any machine that you retrofit with it, hobby or professional.
To answer your other comment;
The entire concept of using G-code for a PnP machine is not a good idea on
any level. However, Linuxcnc can help here. You can control Linuxcnc
directly with its Python API, so it would be a good match to use Linuxcnc
to handle the realtime robotics and IO, but the PnP logic would have to be
created. If someone were to do this (properly), such a project would be a
likely retrofit for old PnP machines.
-Neil-



On Sat, Dec 26, 2015 at 4:55 PM, Jon Elson  wrote:

> On 12/26/2015 12:36 PM, Neil Whelchel wrote:
> > Hello Chris,
> > The reference to MyData is a pick and place machine that is used to
> > assemble circuit boards. Check out
> > https://www.youtube.com/watch?v=56hQ0oBJ4xk Those machines are about the
> > best example I can think of for a well done application of Linux and
> > robotics. TpSys (the software that runs the machine) has many
> similarities
> > to Linuxcnc. In addition, TpSys has many features that I would like to
> see
> > in Linuxcnc:
> >
> >
> Is this a stock MyData, or a retrofit?
>
> I have a Philips CSM84, a 1990's P&P machine wi8th a '286
> CPU running it.  it has amazing ability to handle pick-up
> errors and just keep running.  Mine doesn't have the vision
> system, so chuck jaws are how the small parts are aligned.
> It has a mechanical alignment station for the big chips.
>
> I've looked at some software such as openPnP, but they
> really seem to have no error recovery function.  I know I
> could retrofit my machine with LinuxCNC if I ever needed to,
> but strict G-code would not allow any error recovery.
>
> So, I'm interested in what you have running, there, on the
> MyData.
>
> Thanks,
>
> Jon
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello EBo,
My responses are included below.
-Neil-


On Sun, Dec 27, 2015 at 12:35 PM, EBo  wrote:

> On Dec 27 2015 10:47 AM, Jon Elson wrote:
> > On 12/26/2015 07:59 PM, Neil Whelchel wrote:
> >> Hello Jon,
> >> It is not a retrofit. MyData has used Linux since about 1993 on all
> >> of
> >> their machines,
> >
> > WOW, I'd never heard this!
>
> I did a little fact checking on the net and could not immediately
> verify.  If this is truly the case, it is likely one of the oldest (if
> not oldest) commercial use of Linux out there (and has a 22 year success
> rate running in industrial operations).  That would be big PR for both
> MyData and Linux.  We should verify this and document it on Wikipedia
> and elsewhere.


I have been using Linux in embedded systems since late 1992. Most of these
systems were used in plastic injection machines, and sequence controllers
used in manufacturing. In early 1993, I used Linux for an embedded phone
switch. I am not sure at what point MyData started working with Linux, but
it is possible that my work pre-dates that.
MyData, is now MyCronic. I am not sure how many of the old staff is still
available, but I don't think that it would be too hard to get ahold of
someone.

>>   for a short time before that they used Xenix, but the Xenix
> >> versions never worked well.
> >
> > I have heard there were problems with the older MyData
> > machines just going crazy sometimes.
> >
> >>   The software is called TpSys, it is a
> >> collection of C, Perl, and bash programs, about 300 of them. The
> >> design is
> >> fantastic and well thought out. They are also extremely reliable,
> >> and
> >> stable both hardware and software.
> >> Here is a video of someone setting up a machine, this video is one
> >> of the
> >> few that allows you to see the UI.
> >> https://www.youtube.com/watch?v=UdJxuux0r28
> >> Here is a video of the machine in action. The red flash that you see
> >> is the
> >> up looking camera. It looks at the parts that the 9 vacuum tweezers
> >> (nozzles) are holding as they move past to make a precise
> >> measurement of
> >> the locations of the pins on the parts so that it can calculate the
> >> position offset and rotation of the part when it places it on the
> >> board.
> >> These machines typically place pins to within 0.0005 inches.
>
> two things come to mind here.  If MyData is Linux based, then we should
> be able to request a copy to study and learn what that tells us about
> how the UI is designed.
>

MyData has been quite closed about their software. It is not open source.
As I said before, I am extremely familiar with it, and I can provide
information about how it works.


> Also, you should be able to do something similar with the cameras.  If
> it were me I would start with, and Nick I know this might touch a button
> ;-), to start with OpenCV get the algorithms down and then move onto
> something less heavy weight unless we want to keep the power of OpenCV.
> Implementing something like a Haar transform to detect edges, etc., is
> really not that hard.  I would want to do things with it like find the
> centroid of a hole, a milled pocket, or fiducial mark.  We can use spot
> drilling some holes with an end mill to calibrate the camera position...



> > Hmm, that sounds really GOOD!  I think my repeatability is
> > probably closer to .005" or so.  Just BARELY good enough for
> > anything finer than SOIC lead pitch.
>
> I think you can probably get much, much better than that.  The real
> question is what is the precision of all the various components.  I
> would never expect something like a BlackToe inspired P&P machine
> <https://buildyourcnc.com/PickandPlaceMachineTheredFrog.aspx>to do any
> better than .005" on the TPI, but a general rule of thumb would be to
> have your sensor measure at least 5x (and preferably 10x) what you hope
> to achieve.  That would mean if the MyData can reliably give you .0005"
> that means that the step size of the machine needs to be at least .0001
> or .5" and the pixel resolution would need to be down in the .5"
> or less range.  That is not a problem with macro lenses, and frankly if
> we constrain the system that the center pixel is camera(0,0) then you do
> not have to worry so much about slight variations in the thickness of
> the boards/parts which can/will cause a parallax problem.  Anyway, there
> are simple fixes for that.  We can also look at setting up two or more
> cameras and deriving a simple 3D geometry from the parts -- is it flat?
>
> A big part of the optic

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello EBo,
I am not sure how accurate that the time is in that article. I have a
machine that is stamped with 1995, and I am quite sure it was shipped with
Linux from the factory. I could also be be in error about 1993, it is why I
said "about 1993" because I am not sure as to the exact date. There are
files on my machine that have timestamps as far back as 3/1993, but it is
possible that these files were copied from pre-linux versions.
-Neil-


On Sun, Dec 27, 2015 at 3:17 PM, Ben Potter  wrote:

> > From: EBo [mailto:e...@sandien.com]
> > On Dec 27 2015 10:47 AM, Jon Elson wrote:
> > > On 12/26/2015 07:59 PM, Neil Whelchel wrote:
> >>> Hello Jon,
> >>> It is not a retrofit. MyData has used Linux since about 1993 on all
> >>> of their machines,
> >>
> >> WOW, I'd never heard this!
>
> > I did a little fact checking on the net and could not immediately verify.
> If this is truly the case, it is likely one of the oldest (if not oldest)
> commercial use of Linux out there (and has a 22 year success rate running
> in
>
> > industrial operations).  That would be big PR for both MyData and Linux.
> We should verify this and document it on Wikipedia and elsewhere.
>
> A quick google turns up this link:
> http://www.linuxjournal.com/article/2167?page=0,1
> which indicates 1997 as the changeover date to Linux. Before that they were
> using Venix.
>
> The article could of course be mistaken. There is some interesting stuff in
> there on timing with RT vs non-RT operating systems though.
>
> > I am curious about what they got right and wrong in your opinions.  I
> have
> heard of the project, but never had a need...
>
> Also curious
>
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello Tom,
It is my own A20 board design. I could not find anything (cheap) that has
open drain drivers that can handle 5 amps, along with protected inputs and
a FPGA. I made the board specific for realtime automation.

I call the distro LinuxInside. It is built from source. It uses opkg to
distribute files. I use scripts, patches, and programs from many places,
Debian, OpenWRT, Mikrotik, Gentoo, OpenDesktop and others. It has custom
startup and shutdown programs that are application specific. The instance
that I am using for Linuxcnc is using systemd at the moment, but I may
change that. Part of the problem is related to udev. When a USB device is
plugged in, udev receives messages from the kernel which may cause modules
to be inserted. This is highly likely to cause an interruption of the
realtime services. Part of the plan is to modify udev to watch the state of
Linuxcnc and only take actions when the machine is in "off" state. There
are a number of USB modules that can block things as well, so I will likely
only include very limited USB support for things that are directly required
for Linuxcnc like USB flash drives, buttons, shuttles, and such.
-Neil-


On Wed, Dec 30, 2015 at 10:56 AM, Thomas Gambone II 
wrote:

> Neil,
>
> Are you using an off the shelf A20 board, or did you spin your own?
>
> As for your distro, what was your approach?
>
> Did you start from scratch / Linux From Source approach,
> ending up with your development copy being nearly identical to the
> production copy?
>
> OR
>
> Did you start with a light / customizable distro like gentoo, which has
> package management maintained on the dev side.
> Then you copy a subset of the system to create your production distro?
>
> Continuing Jepler's work with the Odroid boards or similar to make a robust
> embedded controller appliance with LinuxCNC would be excellent to learn.
>
> Thank you,
> -Tom
>
>
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving closer to embedded

[Neil Whelchel]

Hello Gene,
There are many things related to udev and systemd that can cause
interruptions for excess of 200 ms. (This is one of the main reasons that I
refuse to use a desktop type OS on a machine that is cutting on a $20,000
casting.) It is also why I refuse to allow a full keyboard to be connected.
All it takes is someone to hit b (or something similar), and
it is all over unless you do some serious configuration to the kernel and a
dozen other daemons. I am considering dropping the majority of HID support
from my distro to block things like mice and keyboards. My setup is
intended to work only with a touch screen and on screen keyboard. I have
never had any success whatsoever using a mouse in my shop, there is just
way too much dirt, chips, coolant, oil and clutter to make this happen. (I
made the mistake of leaving my laptop near a machine for about 5 minutes,
and I had to spend the rest of the day cleaning aluminum chips and coolant
out of it.)
As I mentioned earlier, I intend to solve the USB storage issue by not
allowing any USB storage devices to be mounted when Linuxcnc is in any
other state than "off".
-Neil-


On Thu, Dec 31, 2015 at 10:16 AM, Gene Heskett  wrote:

> On Thursday 31 December 2015 12:26:01 Neil Whelchel wrote:
>
> > Hello Tom,
> > It is my own A20 board design. I could not find anything (cheap) that
> > has open drain drivers that can handle 5 amps, along with protected
> > inputs and a FPGA. I made the board specific for realtime automation.
> >
> > I call the distro LinuxInside. It is built from source. It uses opkg
> > to distribute files. I use scripts, patches, and programs from many
> > places, Debian, OpenWRT, Mikrotik, Gentoo, OpenDesktop and others. It
> > has custom startup and shutdown programs that are application
> > specific. The instance that I am using for Linuxcnc is using systemd
> > at the moment, but I may change that. Part of the problem is related
> > to udev. When a USB device is plugged in, udev receives messages from
> > the kernel which may cause modules to be inserted. This is highly
> > likely to cause an interruption of the realtime services. Part of the
> > plan is to modify udev to watch the state of Linuxcnc and only take
> > actions when the machine is in "off" state. There are a number of USB
> > modules that can block things as well, so I will likely only include
> > very limited USB support for things that are directly required for
> > Linuxcnc like USB flash drives, buttons, shuttles, and such. -Neil-
> >
> >
> Don't forget that both keyboards and mice are (generally) wireless AND
> USB these days. In my experience it was storage devices with a USB
> interface, like USB keys that play hell with the realtime. It seems the
> filesystem scans them about every 5 seconds, and does it with the IRQ's
> locked out for 200 milliseconds or more.
>
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Difference RTAI 5.0 <--> PREEMPT-rt ?

[Neil Whelchel]

Hello,
To cut to the core, RTAI is basically an interrupt dispatcher that traps
interrupts and re-routes them up either through the RTAI (realtime)
modules, or for non realtime tasks back to the Linux kernel. RTAI also
provides an API for realtime functions, and floating point operations.
The general intent is to run realtime processes in the kernel.
PREEMPT-RT is a configuration option for the kernel to add preemption to
many more places in the kernel, in particular, it makes the spinlocks
preemptable, and it adds a priority tree (priority inheritance). It also
includes changes to the high resolution timer code. It does not introduce
any API, however all timers in user code are replaced with high resolution
timers. There are some issues with PREEMPT-RT and the VGA text console that
have not yet been corrected. (Anything that writes to the VGA text console
such as printk() introduce large unpredictable latencies.) This patch is
intended to run realtime processes in user space, but it also allows
realtime kernel modules to be used.
-Neil-



On Sun, Jan 3, 2016 at 10:06 AM, Karlsson & Wang <
nicklas.karls...@karlssonwang.se> wrote:

> Do anybode know the difference between RTAI and PREEMPT-rt?
>
> Regards Nicklas Karlsson
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] GSOC 2016-Contributing to LINUX CNC

[Neil Whelchel]

Hello,
I can not say enough about how important tapping cycles are. One thing that
would be really handy to have is peck tapping. Currently, I am doing it by
using several G33.1 cycles of greater depth. While this seems to work ok,
there is considerable time wasted between pecks because after the G33.1
cycle ends, it does not continue to synchronize the spindle, and it does a
rapid to the starting position. Then when the next G33.1 is executed, it
must wait for the spindle to come around to the index before feed starts.
It would be REALLY handy to have a G33.1 that works like the peck drill
cycle and keeps the spindle/Z axis synchronized on both reversals as this
would allow partial retracts which would also really speed things up.
-Neil-


On Sun, Mar 13, 2016 at 12:49 PM, John Thornton  wrote:

> The interesting thing about open source software is you have no idea how
> many people use it and what parts they find useful...
>
> JT
>
> On 3/13/2016 2:30 PM, andy pugh wrote:
> > On 13 March 2016 at 00:17, EBo  wrote:
> >> It would also me nice to have the full list of g-codes
> >>  available for discussion
> >> -- even if they are just place holders like:
> >>
> >>   G84 Right-Hand Tapping Cycle:
> >>   This code is currently unimplemented in LinuxCNC. ...
> > We have G33.1 so I assume G84 would just need to be a canned-cycle
> > version of the same. For rigid-tapping arrays of holes.
> >
> > I can see single-digits numbers of users actually using the code.
> >
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Properly dealing with spindle faults

[Neil Whelchel]

Hello,
I was wondering if there are any recommended methods for (properly) dealing
with spindle faults.
On my machine I have the fault output of the spindle controller
(indirectly) connected to the motion.enable input. This works well, when
there is a fault the machine stops and all is good with one major
exception. When the machine is doing a spindle synchronized operation such
as tapping, this causes the motion sync to be broken as well as the tap!
For this to work as expected, there needs to be a way of stopping feed only
when there is no spindle sync, and allowing feed when there is spindle
sync. An ideal behavior would be to immediately raise an error and stop
feed except in the case of synchronized feed. In both cases, the program
should be stopped. The issue with disabling the servo amps (machine off) is
that in the case of several of my machines, the Z axis can move due to
gravity, and this can cause additional damage, so in the case of a spindle
fault, it probably does not make sense to actually power off the machine.
The above could be accomplished if there was an output pin added to
indicate when spindle synchronized motion is enabled.
Another option is to add another pin that is similar to
motion.spindle-at-speed with the exception that is pauses all
non-synchronized feed at any time. This would also solve the issue of
dealing with overloading or otherwise stalling the spindle while it is
cutting.
Thoughts, comments?
Thank you,
-Neil-
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Properly dealing with spindle faults

[Neil Whelchel]

Hello everyone,
Thank you very much for your comments and suggestions. To me the tap is not
the issue, a broken tap in a hole IS an issue, so it is all about not
breaking the tap if the spindle faults out. As long as the axis stays
slaved to the spindle, the tap can be removed by hand. There is not much
point of restarting on the same hole, as that one can be completed by hand
tap if needed. However, having just said that, I have found that since the
axis slave operation starts on the index mark of the spindle encoder, I can
actually tap a hole again, and with quite impressive results. I will look
at motion.feed-inhibit, it looks promising. The docs say that it allows
synchronized motion to complete, but it is unclear if it will work in the
case of manually backing a tap out of a hole. I will report my findings.
Thank you,
-Neil-


On Mon, Mar 28, 2016 at 5:00 PM, EBo  wrote:

> On Mar 28 2016 5:14 PM, Gene Heskett wrote:
> > On Monday 28 March 2016 15:49:49 andy pugh wrote:
> >
> >> On 28 March 2016 at 20:31, Neil Whelchel 
> > wrote:
> >> > When the machine is doing a spindle synchronized operation such
> >> > as tapping, this causes the motion sync to be broken as well as
> >> the
> >> > tap!
> >>
> >> Does motion.feed-inhibit sound like what you need?
> >> http://linuxcnc.org/docs/2.7/html/man/man9/motion.9.html
> >
> > Butting in here, not sure Andy. It seems to me the ideal situation
> > would
> > be to just shut the spindle down, while NOT unlocking the axis that
> > was
> > slaved to it, which might save the tap AND allow hand applied power
> > in
> > reverse to unscrew the tap from the hole with the machine still
> > following the tap back out of the hole. The chances of restarting the
> > operation to finish that hole are somewhere between slim and .1%
> > unless the starting point is saved and can be run back to, which I
> > don't
> > believe is the case now as its forgotten at the end of each run with
> > the
> > current code anyway, but the tap may be saved.  Perhaps this starting
> > point save might be part of this GSOC G33.1 improvement project?
>
> To me saving the part from a broken tap is typically worth more than
> the cost of the tap.  But in either case, a fail safe would be
> preferred.
>
> > ...
> >
> > I received some ER20 collets from China today, but the package
> > labeled as
> > haveing 10 ea 1/8" collets in it, had 10 collets in it, but they were
> > all 3/8' and I already had several of those that I've little or no
> > use
> > for since I don't own 15 ea 3/8 drill bits. :)  Anybody need any 3/8"
> > ER20's? :)  I assume a language barrier.  I'll check on ebay & see if
> > I
> > can get it fixed.  Or just re-order perhaps as I do need another
> > handfull of 1/8" collets in any event.
>
> I will have to check the collet type on the CNC router, but if it is a
> ER20, I would be willing to buy two or more off you.  Do check with ebay
> first...
>
>EBo --
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Properly dealing with spindle faults

[Neil Whelchel]

Hello,
At least with my machine, holding the tap accurately is not an issue. It is
a CAT40 size spindle, and I use good quality collets that that have the
square hole at the bottom that the square end of the tap fits into. They
use in insert to compress around the shank that is like a really short DA
style collet. I have found that the series of taps I buy from Guhring are
very precisely aligned between the threads and the square end, so it is
just a matter of aligning the text on the side of the tap with the + side
of the collet (or using any similar procedure to make sure that the taps
are inserted onto the collet with the same orientation, and fully bottomed
out against the point at the back end of the tap) and it comes out in
exactly the same place every time. This seems to be true even with the
smaller taps such as the M2.2x.45 that I am using on my current job (which
taps 384 holes per operation). If you are having issues with your taps
moving in the collets, I would suggest that you need to think about using
better suited or better quality collets.
The problem I have with my machine is that the spindle motor is 65
horsepower, and unlike the computer and servos, it is not on a UPS.
Sometimes when there is a power surge, it causes the spindle controller to
fault, so even though the power is back on, the spindle coasts to a stop. I
just need a good way of dealing with this. Today, I am going to use a
combination of the controller fault output and the spindle RPM compared
with the near function to drive the motion.feed-inhibit pin and see how
this works.
-Neil-


On Tue, Mar 29, 2016 at 1:40 AM, Gene Heskett  wrote:

> On Tuesday 29 March 2016 03:25:55 Neil Whelchel wrote:
>
> I agree with 90% of that. Restarting the operation here at the
> WOWElectronics shop has generally not been practical because the tap has
> slipped in the chuck, or the whole chuck holding the tap has turned in
> the boring bar type holder I use to hold taps on the carriage of my toy
> lathe.  I lack the ability in a tap holder to grab the square rear end
> of the tap in a tool holder and positively prevent its moving.  If I had
> that problem solved, and I drive the tap to the starting position in my
> G33.1 wrapper, then a rehoming of the lathe should put it close enough
> to restart the hole if the spindle faults because the tap is bigger than
> the spindle can do w/o bogging down.  Editing the wrapper for a smaller
> peck so it doesn't trip off again of course.
>
> Cheers, Gene Heskett
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Properly dealing with spindle faults

[Neil Whelchel]

Update:
I setup my machine to assert motion.feed-inhibit when the spindle falls
below the target RPM. This saved a tool immediately. Within minutes of
starting the test, there was a power surge that caused the spindle
controller to go off-line and the machine stopped feed, saving the tool.
There is one major downside to this, it added 26 minutes to the program I
am currently running. The problem is that the machine does not jog to the
next position until the spindle comes up to speed as it did
with motion.spindle-at-speed, which allows the spindle to come up to speed
while it is jogging to the next cut location. I am thinking that there
needs to be a new pin that behaves like motion.spindle-at-speed with the
exception that it stops unsynchronized feed should the condition become
false again. Or at least a configuration variable that changes the behavior
of the existing pin. Also, another problem that I discovered. During a tap
cycle, if the spindle stops for whatever reason, all is sort of ok... The
problem is that you can not manually back out the spindle because the Z
axis will not back up! The Z axis will only reverse once the tap reaches
the programmed depth. Or if the programmed depth has been reached, the Z
axis will only reverse. I am not sure about the reasoning behind this, but
it seems to me that any time that there is a spindle synchronized movement
like the tap cycle, the axis should be slaved to the spindle no matter
which direction it is turning. I am assuming that the reason that the
slaved axis does not reverse is that it is permitted to use a pulse instead
of a quadrature on the spindle. This seems broken. Maybe there should be an
option to indicate that you are using a quadrature on the spindle so that
direction is accounted for when slaving to the spindle.
-Neil-


On Tue, Mar 29, 2016 at 10:18 AM, Neil Whelchel 
wrote:

> Hello,
> ...
> The problem I have with my machine is that the spindle motor is 65
> horsepower, and unlike the computer and servos, it is not on a UPS.
> Sometimes when there is a power surge, it causes the spindle controller to
> fault, so even though the power is back on, the spindle coasts to a stop. I
> just need a good way of dealing with this. Today, I am going to use a
> combination of the controller fault output and the spindle RPM compared
> with the near function to drive the motion.feed-inhibit pin and see how
> this works.
> -Neil-
>
>
> On Tue, Mar 29, 2016 at 1:40 AM, Gene Heskett  wrote:
>
>> On Tuesday 29 March 2016 03:25:55 Neil Whelchel wrote:
>>
>> I agree with 90% of that. Restarting the operation here at the
>> WOWElectronics shop has generally not been practical because the tap has
>> slipped in the chuck, or the whole chuck holding the tap has turned in
>> the boring bar type holder I use to hold taps on the carriage of my toy
>> lathe.  I lack the ability in a tap holder to grab the square rear end
>> of the tap in a tool holder and positively prevent its moving.  If I had
>> that problem solved, and I drive the tap to the starting position in my
>> G33.1 wrapper, then a rehoming of the lathe should put it close enough
>> to restart the hole if the spindle faults because the tap is bigger than
>> the spindle can do w/o bogging down.  Editing the wrapper for a smaller
>> peck so it doesn't trip off again of course.
>>
>> Cheers, Gene Heskett
>>
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Add features to MUX

[Neil Whelchel]

Hello,
I think that it would really be handy to have more options for the MUX
modules. Specifically, all of the MUX modules are using binary (or Gray) to
select the input. I have a situation where I have a int that I want to use
to select an input, and it just seems messy to convert to binary when the
module could handle that. I have two ideas, and I thought that I would run
this by everyone for an opinion.
1) I will patch the existing modules so that there is a mode that selects
the binary or int input.
2) I will create a whole new mux module that is more flexible in that it
will allow a N amount of instances of N amount of inputs with a choice of
modes when it is loaded.
Now that I am writing this, option 2 seems like the clear winner, but I
just wanted to get everyone's thoughts.
-Neil-
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Add features to MUX

[Neil Whelchel]

Hello,
My mistake, I missed it somehow, forget I said anything... ;)
Thank you for pointing it out.
-Neil-


On Sat, Jun 18, 2016 at 3:22 PM, andy pugh  wrote:

> On 18 June 2016 at 23:09, Neil Whelchel  wrote:
>
> > I think that it would really be handy to have more options for the MUX
> > modules. Specifically, all of the MUX modules are using binary (or Gray)
> to
> > select the input. I have a situation where I have a int that I want to
> use
> > to select an input,
>
> Have you seen mux_generic?
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports. http://sdm.link/zohomanageengine
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc stst changes from master to JointAxis15

[Neil Whelchel]

Hello,
On the subject of Gmoccapy, I think that a REALLY important modification
would be to add a jog wheel mode. This would be a configuration setting
that would replace the jog increment buttons with axis selection and
scaling buttons for the jog wheel.
In my setup, I added five physical lighted buttons for jogging, (X, Y,  Z,
A, and C). The illuminated (last pressed) button is the current jog axis,
and each time the illuminated button is pressed, it changes the wheel scale
downward. IE: wheel x 0.01, wheel x 0.001, and wheel x 0.0001. The workflow
here is press the desired axis button to move the machine near the desired
position, and press again when you are close, and press again to fine tune.
I have considered using a tri color led to indicate the jog scale, but I
think it would be even better if the area of Gmoccapy that is used for
manual jog would display and allow to be set the current jog axis and
multiplier.  Also, it makes sense to have on-screen axis selection buttons
for those people that do not wish to use physical buttons.
If this makes sense to anyone, I will code this up and submit it, or if
someone else is already thinking about this, let me know and we can share
notes.

Also, there needs to be some HAL pins that provide some information on
which mode the machine is in. I think it would be really handy to reset the
state of the physical jog buttons when the machine is changed out of manual
mode. It is also handy to have these pins for the candle as well.

To take this another step;
I also setup my HAL configuration so that if you press more than axis
button at the same time, the jog wheel jogs all of the selected axis. This
is very handy when I am working with multiple fixtures. (I sometimes use
the A and C axis for multiple rotary tables that are both really C axis
tables.)
What I would like to have are buttons to reverse the jog direction or enter
an arbitrary scale between axis when multiple axis are selected.
-Neil Whelchel-


On Wed, Jun 22, 2016 at 12:50 PM, Niemand Sonst  wrote:

> Hallo Dewey,
>
> thanks for your very detailed explanation, most of that is known, but I
> still do not understand why that have been changed, as it does not
> change any behavior, it just makes thinks more difficult for users, used
> to have the same INI settings for several updates.
>
> I have the impression that someone changed that long time ago, maybe
> even by mistake and it has just in there.
> Sorry for my very slow understanding ;-)
>
> It means, that I may have to change some more code in gmoccapy files :-(
> only because a known standard has changed.
>
> By the way, have you seen my new branch gmoccapy_JA?
> I will inform as soon as it is mergable to JA. I still miss the
> modification of the homing and jogging buttons. And find a way to handle
> the differnt modes if a user uses Jogwheels or hardware button.
>
> Norbert
>
> Am 22.06.2016 um 18:52 schrieb Dewey Garrett:
> > The specification of velocities (and accelerations) is
> > confusing because of the multitude of ini settings available
> > in the [TRAJ], [AXIS_ll], [JOINTS_nn], and [DISPLAY] sections
> > of an ini file.  Extra complications may occur because the
> > interpretation of items in the [DISPLAY] section may be
> > GUI-dependent.
> >
> > Note that default values are silently applied (typically from
> > src/emc/nml_intf/emccfg.h) when not otherwise specified and
> > the defaults may not be applicable to a given machine.  The
> > default values seem to be biased to machines with imperial units.
> >
> >> Imho MAX_VELOCITY is the correct nomination, as a circular
> >> move may invoke several axis, is not linear
> > The axis letters X,Y,Z typically specify linear coordinates
> > and may be limited by trajectory planning according to
> > [TRAJ]MAX_LINEAR_VELOCITY.
> >
> > For instance, in joints_axes branches, the velocity of a gcode
> > arc move (g2/g3) using x,y coordinates obeys the F number rate
> > OR is limited to the smallest value allowed by:
> >
> > 1) individual [AXIS_n]MAX_VELOCITY limits
> > or
> > 2) [TRAJ]MAX_LINEAR_VELOCITY
> > or
> > 3) feed override setting
> > or
> > 4) maybe other items i don't know about
> >
> > The [TRAJ]MAX_LINEAR_VELOCITY applies because a g2/g3 movement
> > is for linear coordinates (x,y,z).
> >
> > If a rotary coordinate (typically A,B,C) is specified with g2
> > or g3, then the rotary travel is coordinated to end when the
> > x,y,z motion ends.  As noted in the documentation for g2/g3,
> > "Lines of this sort are hardly ever programmed" It is more
> > common to use inverse feed rate mode (g94) when combining
> > linear and rotary moves.
> >
&g

[Emc-developers] Gremlin parsing code with infinite loops

[Neil Whelchel]

Hello,
When I do large production runs especially with multiple fixtures that are
used alternately, it is quite handy to put the work in an infinite loop.
Gremlin on the other hand has an issue with this as it attempts to backplot
infinity. A comment can be added to the code to make Gremlin ignore it, but
it still throws non fatal Python errors. It would be really handy to have
some sort of checking built into Gremlin to have it not crash when it
encounters an infinite loop. Something as a simple loop counter that breaks
out of the loop after one iteration if all parameters are the same between
any previous pass? Or how about a comment in the NC code that tells gremlin
that a loop is infinite and to only parse it once or N number of times?
Any thoughts or reasons as to why this might be a bad idea, either from the
standpoint of patching Gremlin or writing NC files with infinite loops...
-Neil Whelchel-
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc stst changes from master to JointAxis15

[Neil Whelchel]

Hello,
Yes, Gmoccapy has all of the required pins for using with a jog wheel, that
is what I am doing now, and it really works well.
The issue is that compared to the worst commercial grade controller I have
worked with, is it is a poor hack.
There needs to be some way to show the user what axis is currently
selected, and what the scale is.
This can be added on the side or bottom of Gmoccapy, but I think that it
really needs a jog wheel mode that replaces the on-screen buttons.
Also, it is my opinion that the on-screen axis jog buttons are dangerous. I
have ran into situations where I have an NC file that is more than 200,000
lines of code loaded, and when a jog button is pressed, Gremlin causes long
GUI response lags, and it sometimes takes more than a second for the GUI to
catch up to the fact that you have already taken your finger off of the jog
button.
Even with a jog wheel mode, there is no chance of a lagged out GUI causing
a problem because all of the counts from the jogwheel go through the
realtime code. HAving the GUI lag out when changing scale or axis selection
is really a non-issue as long as the operator watches the GUI to make sure
that the button is actually selected.
-Neil Whelchel-




On Thu, Jun 23, 2016 at 1:51 PM, andy pugh  wrote:

> On 23 June 2016 at 21:27, Neil Whelchel  wrote:
> > On the subject of Gmoccapy, I think that a REALLY important modification
> > would be to add a jog wheel mode. This would be a configuration setting
> > that would replace the jog increment buttons with axis selection and
> > scaling buttons for the jog wheel.
>
> You can set up jogwheel jogging entirely independently of the UI.
> (In fact it is advantageous to do this, as the motion jogwheel pins
> are in realtime code and therefore rather more reliable than UI
> jogging).
>
> I am not familiar enough with Gmoccapy to know if it exports any pins
> that can be used for axis selection.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
>
> --
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Gremlin parsing code with infinite loops

[Neil Whelchel]

Hello,
That is a good point, but I am trying to avoid stopping and restarting the
spindle and such. My spindle motor is a permanent magnet motor, and the
controller does not support a flying start, so the spindle would have to
stop and start for each part set. My spindle is also very high inertia, so
stopping the spindle 2 times a minute would waste a few dozen KW of power
each day (this machine has a 24 KW spindle motor). While I could write a
specific HAL file to fix this, I really don't think that a modification to
the HAL file should really be part of running an NC file. I can run a
program with an infinite loop on my Fagor controller, and it works fine out
of the box, so why do we need to mess with HAL to accomplish what other
controllers do? I realize that my Fagor controller does not backplot, and
there is a price there, but are we thinking clearly when we limit what NC
code can run for this?
The program is about 2500 lines with a loop around it, it runs in about 35
seconds. If I make enough iterations (2471) that the machine can run one
day, Gremlin dies...
-Neil Whelchel-


On Thu, Jun 23, 2016 at 6:23 PM, Dave Cole  wrote:

> You can get around that by not doing infinite loops!  ;-)
>
> Seriously, if you have something like Classic Ladder initiate the
> program you can run as many parts as you want
> and still have the Gcode terminate.   That avoid the infinite loop
> issue.  The needed bits to trigger and monitor the program are all in Hal.
>
> I have a machine that has a PYVCP panel that is tied to Classic
> Ladder.   You enter the number of parts you want to run and push the go
> button,
> the the machine indexes sheets into the machine, cuts them, and indexes
> the cut sheet out the other side.  The operator loads sheets onto a
> conveyor which feeds the machine.
>
> Dave
>
>
>
> On 6/23/2016 5:03 PM, Neil Whelchel wrote:
> > Hello,
> > When I do large production runs especially with multiple fixtures that
> are
> > used alternately, it is quite handy to put the work in an infinite loop.
> > Gremlin on the other hand has an issue with this as it attempts to
> backplot
> > infinity. A comment can be added to the code to make Gremlin ignore it,
> but
> > it still throws non fatal Python errors. It would be really handy to have
> > some sort of checking built into Gremlin to have it not crash when it
> > encounters an infinite loop. Something as a simple loop counter that
> breaks
> > out of the loop after one iteration if all parameters are the same
> between
> > any previous pass? Or how about a comment in the NC code that tells
> gremlin
> > that a loop is infinite and to only parse it once or N number of times?
> > Any thoughts or reasons as to why this might be a bad idea, either from
> the
> > standpoint of patching Gremlin or writing NC files with infinite loops...
> > -Neil Whelchel-
> >
> --
> > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> > Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> > present their vision of the future. This family event has something for
> > everyone, including kids. Get more information and register today.
> > http://sdm.link/attshape
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> --
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Gremlin parsing code with infinite loops

[Neil Whelchel]

Hello Andy,
I am using the magic tags, that is why I wrote my first message here. While
I am using the magic tags, the program below throws python errors, but it
does work once you dismiss the errors.

Program with the actual cutting code removed:
%
(T20  D=0.00049 CR=0 - ZMIN=-0.6746 - TOOL WEAR OFFSET)
(AXIS,stop)
G90 G94 G17 G91.1
G20
G40
G53 G0 Z0
(THREAD1)
T20 M6 G43
S3500 M3
M8
M65 P0
M65 P1
#31 = 0
o101 while [ 1 EQ 1 ]
G53 G0 Z0
o102 if [ #31 EQ 0 ]
(LEFT FIXTURE)
G54
#31 = 1
(WAIT FOR LEFT FIXTURE LOADED INPUT)
M66 P0 L3 Q65535
(CLOSE THE LEFT FIXTURE)
M64 P0
(OPEN THE RIGHT FIXTURE)
M65 P1
o102 else
(RIGHT FIXTURE)
G55
#31 = 0
(WAIT FOR RIGHT FIXTURE LOADED INPUT)
M66 P1 L3 Q65535
(CLOSE THE RIGHT FIXTURE)
M64 P1
(OPEN THE LEFT FIXTURE)
M65 P0
o102 endif
G53 G0 Z0
X0 Y0

... Code to make the part here ...

G40 G0 X0 Y0
G53 G0 Z0
o101 endwhile
M30
%

Thank you,
-Neil Whelchel-



On Fri, Jun 24, 2016 at 10:15 AM, andy pugh  wrote:

> On 24 June 2016 at 17:09, Jeff Epler  wrote:
>
> > I *believe* the special handling code is in the portion that is shared
> > between axis and gremlin, so try using (AXIS,stop) at the point you want
> > to end the preview.
>
> I miss-read the original message, I thought it was rejecting the
> already-existing "magic comments" rather than suggesting magic
> comments.
>
> Neil: http://linuxcnc.org/docs/2.7/html/gui/axis.html#axis:preview-control
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
>
> --
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Gremlin parsing code with infinite loops

[Neil Whelchel]

Hello,
What we are really talking about there are 2 issues:

1) I did this, (AXIS,stop) is in my code, but it still throws a Python
error at line 96 in glcanon.py, which reads:

if command == "stop": raise KeyboardInterrupt

So it seems that raising an exception here is intentional, it is just that
there is nothing above to catch it, so it opens a dialog box containing the
traceback. This seems incorrect to me, does anyone know why this is this
way?
Is there code missing above to catch this?

2) Every other CNC machine I own works just fine with an infinite loop in
the code with the exception of the machines that have LinuxCNC. There are
two ways that this needs to go:

a) There is nothing in the documentation that I can find that prohibits the
use of an infinite loop in NC code, this needs to be addressed (or
otherwise pointed out to me).

b) Gremlin needs to be fixed to handle infinite loops. Or at least fail
gracefully if someone tries to load a program that is otherwise too big to
backplot with the amount of available resources.

I am happy to submit a fix for any of the above, I just need some idea as
to what is the most compatible with the intended direction of the project...
-Neil Whelchel-


On Fri, Jun 24, 2016 at 9:09 AM, Jeff Epler  wrote:

> http://linuxcnc.org/docs/2.7/html/gui/axis.html#axis:preview-control
>
> I *believe* the special handling code is in the portion that is shared
> between axis and gremlin, so try using (AXIS,stop) at the point you want
> to end the preview.
>
> Jeff
>
>
> --
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Hardware, wires and no place to connect

[Neil Whelchel]

Hello,
I have joined this list because I an working on a project to convert my 
old CNC mill and manual lathe to EMC and I saw that there are what seem to 
be limited methods of interfacing EMC to the outside world, and I think I 
might be able to help in this area, among others. Sure there is the 
parallel port, and a hand full of (supported) ISA and PIC boards, but none 
of them seem to provide an optimal interface, and others are simply not in 
the right price range to make a project feasible. I have been tossing 
around the idea for a few months now of creating some very cheap (open 
source) microcontroller based I/O modules that communicate using Ethernet 
at the layer 3 level (Network Layer).

I have settled on Ethernet for the following reasons:
1. It is cheap, common, and proven. It's used nearly everywhere and 
generally, computer savvy people know about it.
2. Star topology, if a wire gets disconnected or damaged it only involves 
that link. (Even the cheapest hubs have link indicators making wiring 
problems easy to locate.)
3. It provides electrical isolation by default. (Except when power over 
Ethernet is used, then it is optional.)
4. Low power modules will not require a power supply (to be directly 
connected) as they can be powered over the Ethernet cable (from the hub, 
or an injector).
5. It is generally faster than most other existing I/O module 
interconnection busses.
6. It works over greater distances than most other existing I/O module 
interconnection busses. (Especially when fiber is used between hubs.)
7. It is very tolerant of electrical noise and has a built-in CRC.

I have settled on the layer 3 level for the following reasons:
1. It can be done in a few dozen lines of code (it will fit on very cheap 
microcontrollers, currently less than $5 U.S.).
2. There is no reason for the packets to travel across a WAN. (Since a 
host computer will be used, WAN access can be accomplished there.)
3. Latency is less and more predictable, and access to the media can be 
scheduled in reatime.
4. Packets will only be a few bytes, and all the same size. (46 bytes, 
the minimum Ethernet II packet payload.)
5. It is very easy to detect and identify unknown modules on the network. 
(For example a list of connected modules and their attributes could 
be generated, no need to manually plug in addresses.)
6. The MAC address is the most suitable way of addressing modules, no 
configuration, no chance of having address conflicts.

I am considering several types of modules:
1. Basic I/O: Bitmapped input and output. Requires a read from the host.
2. Advanced I/O: Sends a timestamp and event to a destination when a 
watched for input occurs. Set output pins according to a timestamp. (For 
example, a MAC address and target could be specified per input pin making 
it possible for an input change in one module to change an output in 
another module without involving or needing the host.)
3. Analog I/O.
4. Advanced analog I/O, (same concept as advanced I/O above 
except analog) including signal generation.
5. Quadrature up/down index counter.
6. Stepper motor driver.
7. AC (three phase) motor driver.
8. DC motor driver.
9. Combinations of any of the above.
10 ...

>From my point of view the biggest problem is interfacing HAL with all of 
the Ethernet cards on the market. It is unlikely that I will be able to 
use the OS provided driver because the transmit and receive queues will 
make it very tough to get realtime access to the media. Also, there are a 
number of Ethernet cards that simply wouldn't work well because of their 
internal buffering, however, it may be possible to predict latency and use 
timestamps to have a delayed, but accurate timebase. I have to do some 
real world testing of the various Linux drivers to see if it is possible 
to get good enough timing, or if I will have to make my own drivers and 
HAL interface.

So, at this point, I am interested in hearing feedback on the concept, the 
good, the bad and the ugly! The reason being is that I want to make sure 
that this idea is useful enough to others before I start dedicating my 
time to taking this project to the next step.

-Neil Whelchel-
C-Cubed
760 366-0126
- I don't do Window$, that's what the janitor is for -

innovate, v.:
To annoy people.

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware, wires and no place to connect

[Neil Whelchel]

Hello,
I guess I should have been more specific when I was discussing the 
topology about connecting to a WAN, or even a non-related internal 
network. I had intended to imply that 
the WAN/LAN and the module network would be separate, one network card for 
each. However, with a proper VLAN switch, I feel that it MAY be possible 
to combine them, but I am not going to spend any time on that. ;)
I have looked into a few realtime Ethernet papers and implementations such 
as Rtnet, Rether, and MicroNet, and it appears that Rtnet has most of 
what is needed for the host side (if not work just fine as-is). However 
for the I/O module side, the Ethernet stacks by Atmel and the like are 
nearly useless to me because they are targeted 
for much more complex (expensive) microcontrollers. (The compiled 
Atmel stack is nearly 3 times the size of the total flash of the 
microcontroller I am considering using.) Call me cheap, you'd be 
right, but why throw all of the complexity and money at it when it is 
likely that the cheaper, simpler approach is likely to provide the best 
answer.

-Neil Whelchel-
C-Cubed
760 366-0126
- I don't do Window$, that's what the janitor is for -

Can anything be sadder than work left unfinished? Yes, work never begun.

On Sat, 29 Mar 2008, Jon Elson wrote:

> Neil Whelchel wrote:
>> Hello,
>> I have joined this list because I an working on a project to convert my
>> old CNC mill and manual lathe to EMC and I saw that there are what seem to
>> be limited methods of interfacing EMC to the outside world, and I think I
>> might be able to help in this area, among others. Sure there is the
>> parallel port, and a hand full of (supported) ISA and PIC boards, but none
>> of them seem to provide an optimal interface, and others are simply not in
>> the right price range to make a project feasible. I have been tossing
>> around the idea for a few months now of creating some very cheap (open
>> source) microcontroller based I/O modules that communicate using Ethernet
>> at the layer 3 level (Network Layer).
> There is a real-time Ethernet driver already in existance, but
> there are a number of restrictions on how it works.  Also, these
> restrictions means it won't work with off the shelf ethernet
> micros and their off the shelf ethernet stacks, such as Atmel
> and NXP make.  At least, that was my understanding.  Whether the
> micro's library can be adjusted to make it work with the RT-net,
> I don't know.  The RT-net requires total isolation of the RT
> part from the WAN with a router that can handle the RT-net
> flavor, so that pretty much has to be another computer with two
> ethernet cards/ports.
>
> I wanted to provide an ethernet interface to my boards, which
> are parallel port based right now.  But, this was just over my
> head and beyond the time I had available.
>
> Jon
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware, wires and no place to connect

[Neil Whelchel]

Hello,
It is too early to tell what the reasonable maximums are, I will have a 
better idea when I build a few modules. However, I have plans to count 16 
bits worth of changes, so reading the register 10 times a second would be 
able to count just about 65536/2*10=327680 per second. With an encoder 
with 1024 counts per rev, this works out to be 327680/1024*60=19200 rpm!
The microcontroller will be able to handle up to about 4.5 MHZ worth of 
input pulses. I see the major limiting factor here as the response time 
from the encoder itself, there are very few encoders around that don't 
start missing pulses at around 150 khz, ones with less counts per rev can 
usually exceed this however, but look at the resulting RPM..
Also, when very large RPM ranges are needed, a common trick is to use 2 
encoders, one with a high pulse count for fine positioning, and another 
with a low pulse count for high speed rough position. When the RPM falls 
below a certain point, a calculation is made to determine the offset to 
the high res pulses, and the handoff is made. (This is sometimes done in 
the same physical encoder using only the index pulse above a certain RPM.) 
What could you possibly need 100,000 counts per second for?

-Neil Whelchel-
C-Cubed
760 366-0126
- I don't do Window$, that's what the janitor is for -

Intolerance is the last defense of the insecure.

On Sun, 30 Mar 2008, Mario. wrote:

> Okay, if you can do turnaround of at least 100 thousand output hardware
> changes per second, I'm in. Quadrature outputs.
>
> On 3/30/08, Neil Whelchel <[EMAIL PROTECTED]> wrote:
>>
>> Hello,
>> I guess I should have been more specific when I was discussing the
>> topology about connecting to a WAN, or even a non-related internal
>> network. I had intended to imply that
>> the WAN/LAN and the module network would be separate, one network card for
>> each. However, with a proper VLAN switch, I feel that it MAY be possible
>> to combine them, but I am not going to spend any time on that. ;)
>> I have looked into a few realtime Ethernet papers and implementations such
>> as Rtnet, Rether, and MicroNet, and it appears that Rtnet has most of
>> what is needed for the host side (if not work just fine as-is). However
>> for the I/O module side, the Ethernet stacks by Atmel and the like are
>> nearly useless to me because they are targeted
>> for much more complex (expensive) microcontrollers. (The compiled
>> Atmel stack is nearly 3 times the size of the total flash of the
>> microcontroller I am considering using.) Call me cheap, you'd be
>> right, but why throw all of the complexity and money at it when it is
>> likely that the cheaper, simpler approach is likely to provide the best
>> answer.
>>
>>
>> -Neil Whelchel-
>> C-Cubed
>> 760 366-0126
>> - I don't do Window$, that's what the janitor is for -
>>
>>
>> Can anything be sadder than work left unfinished? Yes, work never begun.
>>
>>
>> On Sat, 29 Mar 2008, Jon Elson wrote:
>>
>>> Neil Whelchel wrote:
>>>> Hello,
>>>> I have joined this list because I an working on a project to convert my
>>>> old CNC mill and manual lathe to EMC and I saw that there are what seem
>> to
>>>> be limited methods of interfacing EMC to the outside world, and I think
>> I
>>>> might be able to help in this area, among others. Sure there is the
>>>> parallel port, and a hand full of (supported) ISA and PIC boards, but
>> none
>>>> of them seem to provide an optimal interface, and others are simply not
>> in
>>>> the right price range to make a project feasible. I have been tossing
>>>> around the idea for a few months now of creating some very cheap (open
>>>> source) microcontroller based I/O modules that communicate using
>> Ethernet
>>>> at the layer 3 level (Network Layer).
>>> There is a real-time Ethernet driver already in existance, but
>>> there are a number of restrictions on how it works.  Also, these
>>> restrictions means it won't work with off the shelf ethernet
>>> micros and their off the shelf ethernet stacks, such as Atmel
>>> and NXP make.  At least, that was my understanding.  Whether the
>>> micro's library can be adjusted to make it work with the RT-net,
>>> I don't know.  The RT-net requires total isolation of the RT
>>> part from the WAN with a router that can handle the RT-net
>>> flavor, so that pretty much has to be another computer with two
>>> ethernet cards/ports.
>>>
>>> I wanted to provide an ethernet interface to my boards, whi

Re: [Emc-developers] Hardware, wires and no place to connect

[Neil Whelchel]

Hello again,
Once again, it looks as if I should have been more specific.. ;)
I will define some terms I used..
Cycles: A complete cycle of BOTH the A and B signals from the sensor.
Pulses: Maybe not an exact term, but this refers to a cycle from ONE of 
the signals either A or B.
Counts: A count is derived from the quadrature input and can be any of 1, 
2, 3, or 4 increments per cycle. Yes, there are three counts per cycle 
actually in use, this provides an alternate wide and narrow step, when 
used in conjunction with custom patterns on the encoder wheel can provide 
some very useful information, slot machines are among some things that use 
this.
When I was talking about 1024 counts per rev, I was referring to an 
encoder wheel with 256 slots, holes, magnetic flux changes, capacitive 
strips, reflective spots, or conductive spots, I'm sure I left more than 
one off this list. :)
As far as your stepper machine with 256,000 steps per inch, I fail to see 
why you would need an encoder that matches that resolution (.00390625 
per step), my electron microscope stage is only 50,000 steps per inch.
I can see why you would need so many steps per inch to get the needed 
torque, but that has nothing to do with the the encoder.
Also, I'd like to make it clear that I am not attacking anyone's ideas 
here, I really appreciate your input, it will help me make better design 
decisions. If there is a real need for very high count rates, I will be 
forced to include it in the design, however for jogging speeds with very 
high speed motors and very fine encoders, the usual technique is to use 
only the index pulse (or a second encoder or track on the same 
encoder that has a much lower resolution) above a certain speed. For 
example when using a 1024 count per rev encoder, when the pulse frequency 
gets over 100,000 counts per second, wait for the next index pulse to come 
by, then switch to counting only index pulses and either add or subtract 
1024 to the total count for each index. As soon as the speed is back to 
something lower than 100,000 counts per second, flip back to counting 
actual pulses.
As far as generating steps, I don't see a problem with going into the MHZ 
on that side..

-Neil Whelchel-
C-Cubed
760 366-0126
- I don't do Window$, that's what the janitor is for -

Diplomacy is to do and say, the nastiest thing in the nicest way.
-- Balfour

On Mon, 31 Mar 2008, Jon Elson wrote:

> Neil Whelchel wrote:
>> Hello,
>> It is too early to tell what the reasonable maximums are, I will have a
>> better idea when I build a few modules. However, I have plans to count 16
>> bits worth of changes, so reading the register 10 times a second would be
>> able to count just about 65536/2*10=327680 per second. With an encoder
>> with 1024 counts per rev, this works out to be 327680/1024*60=19200 rpm!
>> The microcontroller will be able to handle up to about 4.5 MHZ worth of
>> input pulses. I see the major limiting factor here as the response time
>> from the encoder itself, there are very few encoders around that don't
>> start missing pulses at around 150 khz,
> Well, 150 KHz on the actual A and B encoder signals is 600,000
> quadrature counts/second.  At 1000 cycles/rev or 4000 quad.
> counts/rev, that is 150 revs/second or 9000 RPM.  Will your
> motors be running that fast?
>  ones with less counts per rev can
>> usually exceed this however, but look at the resulting RPM..
>> Also, when very large RPM ranges are needed, a common trick is to use 2
>> encoders, one with a high pulse count for fine positioning, and another
>> with a low pulse count for high speed rough position. When the RPM falls
>> below a certain point, a calculation is made to determine the offset to
>> the high res pulses, and the handoff is made. (This is sometimes done in
>> the same physical encoder using only the index pulse above a certain RPM.)
>> What could you possibly need 100,000 counts per second for?
> Well, with a 1000 cycle/rev encoder, that is 25 revs/sec or 1500
> RPM.  That is not very fast for a small servo motor.
> I have 1000 cycle/rev encoders on some of the motors I have used
> on my minimill.  It has 4:1 belt reduction and 16 TPI screws.
> So, that is 4000 * 4 * 16 = 256000 counts/linear inch motion.
> At 60 IPM=1 Inch/Sec, that is 256000 quadrature counts/second.
> That is also 3840 RPM at the motor.
>
> Jon
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ___
> Emc-developers mailing list
> Emc-develop

Re: [Emc-developers] Hardware, wires and no place to connect

[Neil Whelchel]

Hello,
What you are talking about here is a rotary transformer (resolver). I have 
not put 
much thought into a rotary transformer interface as of yet, however I may 
make one in the future. Keep in mind, however, most of the (older) rotary 
transformer applications were done by sending a pair of PWM signals to the 
stationary windings (sine/cosine), the resulting signal from the rotor 
winding was used to produce an analog voltage to control the motor amp. 
The motor would run to move the rotor to where there was zero output from 
the rotor winding. (There was usually a motor tachometer signal that was 
inverted and mixed with this, so the error in position was converted to a 
speed.) Jogging was accomplished by setting the sine/cosine to the rotary 
transformer to the destination position, then overriding the output from 
the rotor winding and forcing the amp input to a specific voltage while 
counting the zero crossings from the rotary winding. When the destination 
is within the last zero crossing, the amp override is removed, and the 
output of the rotor winding (and tach) is used to settle into the final 
position. (At the end of the day, this still ends up as the same concept 
as ignoring the quadrature and only counting index pulses above a certain 
speed as I had discussed before.)
I have seen some newer methods that simply convert the rotary transformer 
signals to counts which are read by a computer which does some 
calculations to come up with motor driving values, and while many claim 
that these work just as good as the old analog stuff, I have yet to see 
this proven in the field. (I am sure I stepped on a few toes with 
that comment, and many are likely to disagree, but I must point out 
that those old designs used DC brush motors and analog amps, the only 
digital signals were the PWM inputs to the transformers, the result 
was a VERY smooth operation that has been proven as difficult to 
obtain with much more complex digital control.) Also, while I am on this 
subject, the 
electronics that convert the rotary transformer signals to counts only run 
a few hundred times per second, in some very high speed stuff I have seen 
as high as 2 khz, but this is also VERY rare, because once the speed 
exceeds a certain point, it is assumed that the resolver has turned more 
than 180 degrees since the last check and this is simply added to the 
result. This approach, given the inertia of the motor and every other 
moving part causes a limited amount of change over time so it becomes 
just as easy in software to determine if the transformer has turned 
once or a hundred times since the last sample. The position of the 
transformer can move 
thousands of counts (or full turns) in either direction between checks 
which is just fine 
because the result is absolute within 180 degrees (90 or 45 depending 
which transformer is used). So let's say that you check the resolver 100 
times per second, this gives you a 3000 RPM before you 
have to assume that the transformer has rotated more than 180 degrees, 
then your next position reading is however many counts for 180 degrees 
plus the current position. Once you cross the 6000 RPM mark, you simply 
add the amount of counts for 360 degrees each time. Since the transformer 
is usually mounted directly to the screw and not the motor, that 
translates to 3000 SCREW rpms before you have to add counts. And by the 
way, most rotary transformers are good for up to 200 counts per 180 
degrees, after this point the distance between steps becomes inaccurate at 
various locations due to manufacturing limitations. This is much less of a 
problem with the analog approach I discussed above.

-Neil Whelchel-
C-Cubed
760 366-0126
- I don't do Window$, that's what the janitor is for -

Show business is just like high school, except you get paid.
-- Martin Mull

On Mon, 31 Mar 2008, Mario. wrote:

> The very basic motion resolution. Say you want a 1um resolution of a
> step (no matter how of whether you achieve that), but you also want to
> keep maximum traverse travel speed of 2m/s. That would need 2 milion
> steps per second. (Now we don't discuss that without linear drive you
> can not have accuracy better than 50 microns ;-)) All I asked for is
> GOOD *output* resolution. You simply NEED to have the potential there.
>
> As for the input... the encoders used for high microstep rate per
> second are all analog sine/cosine, so that the 14-bit ADC resolution
> (used to be 12-bit and 14-bit, not 16-bit up to 18-bit is possible) is
> capable of those say 100KHz per second. Say you divide those 10
> microsecond whole sine/cosine periods into only 100 parts and you
> suddenly ended with some 10 milion microsteps per second.
>
> Canon makes LCD litography equipment and the old projector could move
> the positioning table (with about 2x3m glass on it) 500 milimeters in
> half a second. All with ac

Re: [Emc-developers] Hardware, wires and no place to connect

[Neil Whelchel]

Hello again,
Thanks for pointing out the chip, it could be quite useful, I will 
consider it when (if) I start thinking about making resolver modules, 
however, I don't like the $13/100 price.. It is very typical of the modern 
implementations of converting a resolver to digital counts (which I 
personally don't much care for), afterall a resolver was intended as an 
analog position sensor, now days we have things like hall, CCD, and capacitive 
sensors, other than a few specific cases, there is not too much point in 
using a resolver unless it is a refit of existing equipment IMHO. ;)

-Neil Whelchel-
C-Cubed
760 366-0126
- I don't do Window$, that's what the janitor is for -

When the going gets tough, the tough go shopping.

On Mon, 31 Mar 2008, Jon Elson wrote:

> Neil Whelchel wrote:
>> Hello,
>> What you are talking about here is a rotary transformer (resolver). I have
>> not put
> Analog Devices makes the AD2S1200, a complete, single-chip
> resolver to digital converter.  It costs ~ $20 in single
> quantity.  it has the reference oscillator, sense amps and all
> the deciphering circuits.  It can produce a binary digital
> position value or quadrature outputs to simulate an encoder.
> The only thing you need to add is a simple output driver.
> It produces 1024 quadraure counts/cycle of the resolver.
>
> Jon
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware, wires and no place to connect

[Neil Whelchel]

Hello again,
Ok, stepper motor, or servo, it really doesn't make any difference, I had 
assumed that your reason was for torque, not precision. I can see that 
your point is that you want to record/produce ALLOT of steps in a short 
time, which is understandable for projects with limited resources. 
However, in such cases, I would suggest multiplying steps to bring a step 
size (up) to something more reasonable, or in the other direction around, 
using a lower resolution encoder. In the real world, I have found little 
use for more than 100,000 steps per inch, and that is even pushing it a 
bit. ;) Most CNC software only carries out positioning to 10,000 steps per 
inch.
I am just trying to be careful with high frequency stuff because it ends 
up being much more complex and sensitive to cabling issues and noise, 
which simply reduces the chances of overall success, especially when there 
are other methods available.

As far as your suggestion about losing track of position by switching 
from/to the index pulse above/under certain speeds, you will have to build 
a better case.. ;) Let's say that we can count individual pulses under 
3000 RPM, and our target speed is 1 RPM. Then in this case, we could 
use say 2000 RPM as a handoff, this way we still have 1000 RPM overhead, 
and we know that in the time of one revolution it would be impossible to 
go from 2000 RPM to over 3000. So far, as long as all of the hardware and 
electrical stuff works fine, we would never lose count. So as the shaft 
accelerates through the 2000 mark, we know exactly when the index will 
come around, and what our count will be at that point, if all is as 
expected, we simply ignore the quadrature, and look within a small 
time window (just wide enough to account for possible 
acceleration/deceleration) in for the next index pulse. If the pulse shows 
up as expected, add/subtract however many counts of one rev to it, and 
re-adjust the window. Then when the speed falls below the handoff, we know 
that we will have a good quadrature and it will line up with the index, so 
the handoff is made. In both cases we have a way of checking for failure, 
when running slow, if the index is in the wrong place, we know we missed a 
count somewhere, in the other case, if the index appears at the wrong 
time, we also know we missed something. By the way, when we are only 
counting index pulses, we can still get a fairly accurate position based 
on the time window. Since we know how much time until the next index pulse 
shows, we also can add an appropriate amount of counts to the output data 
if a read occurs at some time other than when the index pulse is seen 
(which is almost always the case). For example one of the projects I did 
in the past was to sense the position of a turbine engine shaft turning at 
80,000 RPM using only one PPR. It was a trivial matter to get 1000 counts 
per rev with an error of less than 2 counts per rev.
I just don't see any viable situation that would cause you to lose track..
And afterall, what I am talking about here is more of a limitation of the 
quadrature encoder than the decoder. I am talking about a work around for 
a slow encoder, not a workaround for a slow computer/decoder.

-Neil Whelchel-
C-Cubed
760 366-0126
- I don't do Window$, that's what the janitor is for -

"Ask not what A Group of Employees can do for you.  But ask what can
All Employees do for A Group of Employees."
-- Mike Dennison

On Mon, 31 Mar 2008, Jon Elson wrote:

> Neil Whelchel wrote:
>> As far as your stepper machine with 256,000 steps per inch,
> It is not stepper, but servo.  The belt ratio was chosen to get
> sufficient torque to the leadscrew, not for reason of resolution.
>  I fail to see
>> why you would need an encoder that matches that resolution (.00390625
>> per step), my electron microscope stage is only 50,000 steps per inch.
>> I can see why you would need so many steps per inch to get the needed
>> torque, but that has nothing to do with the the encoder.
>> Also, I'd like to make it clear that I am not attacking anyone's ideas
>> here, I really appreciate your input, it will help me make better design
>> decisions. If there is a real need for very high count rates, I will be
>> forced to include it in the design, however for jogging speeds with very
>> high speed motors and very fine encoders, the usual technique is to use
>> only the index pulse (or a second encoder or track on the same
>> encoder that has a much lower resolution) above a certain speed.
> This seems like an excellent way to lose position.  The
> realignment of the counters has to be perfect, EVERY time.
> I can see why such stuff was done back in the days of discrete
> transistors and early TTL, but it doesn't make sense anymore.
>
> Jon
>
> 

Re: [Emc-developers] Hardware, wires and no place to connect

[Neil Whelchel]

Yup, $13 is a high price. I am trying to make the 
modules as low cost as possible without cutting any performance corners.

-Neil Whelchel-
C-Cubed
760 366-0126
- I don't do Window$, that's what the janitor is for -

The revolution will not be televised.

On Mon, 31 Mar 2008, Jon Elson wrote:

> Neil Whelchel wrote:
>> Hello again,
>> Thanks for pointing out the chip, it could be quite useful, I will
>> consider it when (if) I start thinking about making resolver modules,
>> however, I don't like the $13/100 price.. It is very typical of the modern
>> implementations of converting a resolver to digital counts (which I
>> personally don't much care for), afterall a resolver was intended as an
>> analog position sensor, now days we have things like hall, CCD, and 
>> capacitive
>> sensors, other than a few specific cases, there is not too much point in
>> using a resolver unless it is a refit of existing equipment IMHO. ;)
> Clearly true.  But, a lot of older machines DO have very nice
> resolvers integrated in ways that make them difficult to replace
> with modern encoders.  That is the only reason to use them, as
> you can get very good new encoders at reasonable prices, and use
> the signals directly.  There's no way a resolver PLUS a
> converter board will ever be that cheap.  But, if it involves
> major surgery to replace a deeply integrated resolver, then it
> might be reasonable.
>
> $13/100 scares you?  I'm stuck using $35 FPGAs until I get a new
> version of one of my boarda working.
>
> Jon
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers