Re: [Emc-users] Sattelite IO-controller.

[Ray Henry <rehenry@up...>]

Hi Einer

Good thoughts.  Way beyond my modest understanding of PIC programming.  I 
was thinking only of using the serial line to convert a bunch of signals 
from pins on the end of the wire to serial then return them to a parallel 
representation within an EMC driver program.  

Are you suggesting that we could implement string parsing and pass common 
language commands that will set up the PIC or AVR to accept data and 
apply logic to the data based on that string?  If yes, I'd suggest that 
we add variables to the INI file that reference both a specific EMC 
serial driver, the characteristics of the port to be used, and a file 
that contains the code to be sent to setup the chip on the other end of 
the wire.

I believe that work on this will be very rewarding for all of us.

Ray
 


On Friday 19 December 2003 3:55 am,  wrote:
> > Once we get that together we would want to get a list of the
> > command/controls so we could figure out
> > what the serial command string will need to be like.
>
> Absolutely.
> As I and probably others doesn't have a clue on PIC but prefer AVR, we
> need a well defined interface. Otherwise we're back to today's
> situation where only the high priests know how to replace a module. So
> put effort into defining the commands, and maybe a protocol.
>
> And remember that a modern uC have quite powerful peripherals. So
> counting, timing, ADC and many other functions can be done more easily
> and cheaper there. Often just a few lines of code after the part is
> initialized. No problem with realtime either, except it may need to be
> synced with PC better than RS232 or USB can do. One easy solution to
> this is to have a synch line where a command can be sent out on serial
> line like this: "Release spindle brake 130uS after next synch". Or "All
> sattelites latch & store their counters at next synch." This can then
> actually be done with sub-microsecond precision on most uC's.
>
> And another feature: low price. An ATtiny15 is $2 in small qty. With a
> bunch of features. To avoid religious wars i should say PIC and other
> ranges have similar devices.
>
> What these devices typically do not have is lots of RAM. So they should
> be fed with commands and requests as they are required, not for
> execution in some distant future.
>
> And a plea: *Please* prune your replies before sending, and turn off
> HTML and RTF. I read this list in digest mode, not using a Microshaft
> reader, and sometimes it is close to impossible to distinguish new and
> old content.
>
> Einar Sjaavik
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for
> IBM's Free Linux Tutorials.  Learn everything from the bash shell to
> sys admin. Click now!
> http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Emc-users mailing list
> Emc-users@...
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] twincat plc/NC-System

[Till Franitza <till.franitza@is...>]

When you are thinking about how a PC-based NC/PLC could be like, you may
find it very inspiring to have a look at the Homepage of http://www.beckhoff.de .
They Offer a TWINCAT, a "Totally Windows-INtegrated (realtime) Control and
AuTomation environment. You can download it and use it for 30 days. After
that, you can simply deinstall it or install it again and have another 30
Days.
I am using it and i think ist gives an excellent example on how
user-friendly and intuitive such a system can be. The configuration process
is very simple and windows-like.
I hope you do not consider this as advertisement. I am not employed by
beckhoff.
regards,
till

[Emc-users] Sattelite IO-controller.

[<einarp@ma...>]

> Once we get that together we would want to get a list of the 
> command/controls so we could figure out
> what the serial command string will need to be like.

Absolutely.
As I and probably others doesn't have a clue on PIC but prefer AVR, we need a
well defined interface. Otherwise we're back to today's situation where only the
high priests know how to replace a module. So put effort into defining the 
commands, and maybe a protocol.

And remember that a modern uC have quite powerful peripherals. So counting,
timing, ADC and many other functions can be done more easily and cheaper there. 
Often just a few lines of code after the part is initialized. No problem with realtime 
either, except it may need to be synced with PC better than RS232 or USB can do. 
One easy solution to this is to have a synch line where a command can be sent out 
on serial line like this: "Release spindle brake 130uS after next synch".
Or "All sattelites latch & store their counters at next synch." This can then actually be
done with sub-microsecond precision on most uC's.

And another feature: low price. An ATtiny15 is $2 in small qty. With a bunch of 
features. To avoid religious wars i should say PIC and other ranges have similar
devices.

What these devices typically do not have is lots of RAM. So they should be fed with
commands and requests as they are required, not for execution in some distant
future.

And a plea: *Please* prune your replies before sending, and turn off HTML and RTF.
I read this list in digest mode, not using a Microshaft reader, and sometimes it is
close to impossible to distinguish new and old content. 

Einar Sjaavik

Re: SV: [Emc-users] How do I disable one axis?

[Jon Elson <elson@pi...>]

Anders Blix wrote:

>Ok, thanks. That is along the lines I was thinking I would have to do.
>
> 
>
>But it appears that one switch was in the wrong position. You were right Jon, I had accidentally set axis 0 in phase mode...... DAMN that took me a long time and a lot of effort to figure out! Phew, but now I think I'm up and running. 
>  
>
Oh MAN!  That has got to be the wierdest one I've had yet.  And, I BARELY
even thought to mention the switches!

> 
>
>But now I've run in to another problem and that is to change monitor. I have now FINALLY moved the computer and motors down in the basement and attached it all to the mill! Wow was I looking forward to finally after MONTHS of working to get this up. 
>
> 
>
>And what awaits me when I finally start the thing......... blank screen! 
>
>My final attempt is to bring my way to expensive for bringing down there in the first place 20" monitor (it is the one I have used while up here trying to make it work so I know it works), and THEN i get picture..... so how do I change monitor type....... this is where I come to the point of finding out that NOW I REALLY HATE OLD LINUX VERSIONS!
>  
>
UGH!  The dark underbelly of Linux comes home to roost!  First thing, 
try CTRL/ALT/+
(that's the + key on the right keypad) which cycles through all 
available video resolutions.
Most likely, you have it set for 1024x768 or 1280x1024 for the big 
monitor, and you need
to step it down to a lower setting.  Once you find what setting works 
(you want at least
800x600 for EMC) You can change the /etc/XF11/XF86Config (sometimes 
XF86Config-4)
script to eliminate the
too-high resolution from the list.  If you can find out what the 
horizontal sync range
for your monitor is, you can put that in the place where it says

Section "Monitor"
    HorizSync  31.5-64.3

or something similar.  (Newer files don't seem to have this section.)

Also, you'll see something like :

    Subsection "Display"
        Depth       16
        Modes       "1024x768" "800x600" "640x480"
        ViewPort    0 0
    EndSubsection
    Subsection "Display"
        Depth       24
        Modes       "1024x768" "800x600" "640x480"
        ViewPort    0 0
    EndSubsection
    Subsection "Display"
        Depth       32
        Modes       "1024x768" "800x600" "640x480"
        ViewPort    0 0
    EndSubsection

It will pick the FIRST acceptable resolution in the list.  If you move 
"1024x786" to the
end of the list, it will try "800x600" first and use that.  This way, 
you'll still have
the 1024 mode accessible with the ctrl/alt/+ key.

> 
>
>Boy was I glad I had an OLD book on Linux in my bookshelf.... Reading in it made me remember that there is a file called X11config or something. Anyway, I'm able to fiddle around with the parameters in there until I'm able to decrease the refresh rate down to what my "mill monitor" can handle. But I'm NO WAY sure I did this the correct way. Is there a program to manage this available for this release of RH? I would like to get that and configure this properly. On my Mandrake box doing this was as easy as doing it in windoze...... things like this makes the BDI 2.20 installations rather vulnerable if you are not Linux experts, and the point of BDI was to help exactly those, weren't it?????
>  
>
You should have xvidtune, but use it with caution, as you can smoke a 
monitor by
changing the horizontal sweep rate too much.

Jon

Re: SV: [Emc-users] How do I disable one axis?

[Ray Henry <rehenry@up...>]

On Thursday 18 December 2003 3:46 pm, Anders Blix wrote:

> And what awaits me when I finally start the thing......... blank
> screen!
>
> My final attempt is to bring my way to expensive for bringing down
> there in the first place 20" monitor (it is the one I have used while
> up here trying to make it work so I know it works), and THEN i get
> picture..... so how do I change monitor type....... this is where I
> come to the point of finding out that NOW I REALLY HATE OLD LINUX
> VERSIONS!
>
>
>
> Boy was I glad I had an OLD book on Linux in my bookshelf.... Reading
> in it made me remember that there is a file called X11config or
> something. Anyway, I'm able to fiddle around with the parameters in
> there until I'm able to decrease the refresh rate down to what my "mill
> monitor" can handle. But I'm NO WAY sure I did this the correct way. Is
> there a program to manage this available for this release of RH? I
> would like to get that and configure this properly. On my Mandrake box
> doing this was as easy as doing it in windoze...... things like this
> makes the BDI 2.20 installations rather vulnerable if you are not Linux
> experts, and the point of BDI was to help exactly those, weren't
> it?????

The way that I do this is switch to a terminal using <control><alt><F2> 
and log in as root.  Enter the command "setup" (without the quotes) and 
select the x configuration tool.  Near the end, it has a test routine, 
keep going around this until you get a screen appearance that you can 
live with.

Hope this helps

Ray

[Emc-users] I'm finally moving my mill now!

[Anders Blix <Anders.Blix@tv...>]

Finally the thing is moving, and things seem to be under control! I =
reached 2400 mm/min (about 95 IPM!!!:-) before my motors begun stalling =
out! And this is without tuning the PID parameters. They seem to be =
about correct already, and I don't think I'll be able to reach much =
higher in speed..... But I'm not even sure I want more :-)
=20
My problems with not reaching faster than 10 kHz proved to be a switch =
in the wrong position (the switch for choosing between Step/Dir and =
phase out on axis 0).=20
=20
I do have some problems with the encoder on my Y axis though. Must be =
mechanical problems, and partly backlash (I'm able to take most of it =
away and I'll look in to that tomorrow as well). I think. At one point =
it was working perfectly, but after doing some testing of holding torque =
it's all messed up and I'm unable to make the axis go at all with =
feedback..... strange phenomenon. It may also be because of to high P. =
I'll have to look at it in the morning, and also attach the encoder on =
the X-axis.=20
=20
But finally, I'll be able to go on and start learning to use it and all =
that. That is a different thing, but hopefully it'll not be that =
difficult and frustrating (at least I hope so...:-)=20
=20
And thanks again to all that have helped me and hopefully others along =
the way. All this have lead to some cleaning up in the CVS repository =
to. And the units for use in EMC 2 (I look forward to test it!!) have =
been questioned and hopefully dealt with in a good way.=20
=20
It would have been completely impossible for me to get it up without =
your help!

	=20

	Anders

Re: [Emc-users] Several Questions

[<jmkasunich@at...>]

Jonathan Stark wrote:
> Quoting jmkasunich@... (jmkasunich@...):

> > This is a natural for the HAL - the HAL philosophy is that EMC itself
> > should never access real I/O devices - it only touches HAL signals/pins.
> > Then drivers transfer stuff from the HAL signals to real-world I/O.
> 
> This is a great step forward.   I just wish it was plugged into emc,
> or that emc2 was far enough along to be useful for me now ;)

So do I...  but these things take time.

> A slightly larger amount of structure, however, such that things
> like step and direction could be combined and rewritten like that
> fellow who had a step ccw and step cw signal rather than seperate step
> and direction signals would be great.

That particular problem is already handled - the HAL stepgen module
has about 15 stepping types, and UP/DOWN is one of them.
 
> So, a lego brick sort of thing where step/dir gets put in as
> inputs, and outputs of that module are CCW step and CW step which
> could then be piped through HAL would be cool.

HAL is exactly that sort of LEGO thing.  Lots of modules, you pick
and choose which ones you need, and connect them to do whatever you
want.  The goal is to make writing new modules relatively simple, so
if you need a custom module you can write it and use it without 
needing to understand the whole monster that is EMC.

John Kasunich
 

[Emc-users] I'm finally moving my mill now!

[Anders Blix <Anders.Blix@tv...>]

Finally the thing is moving, and things seem to be under control! I =
reached 2400 mm/min (about 95 IPM!!!:-) before my motors begun stalling =
out! And this is without tuning the PID parameters. They seem to be =
about correct already, and I don't think I'll be able to reach much =
higher in speed..... But I'm not even sure I want more :-)

=20

My problems with not reaching faster than 10 kHz proved to be a switch =
in the wrong position (the switch for choosing between Step/Dir and =
phase out on axis 0).=20

=20

I do have some problems with the encoder on my Y axis though. Must be =
mechanical problems, and partly backlash (I'm able to take most of it =
away and I'll look in to that tomorrow as well). I think. At one point =
it was working perfectly, but after doing some testing of holding torque =
it's all messed up and I'm unable to make the axis go at all with =
feedback..... strange phenomenon. It may also be because of to high P. =
I'll have to look at it in the morning, and also attach the encoder on =
the X-axis.=20

=20

But finally, I'll be able to go on and start learning to use it and all =
that. That is a different thing, but hopefully it'll not be that =
difficult and frustrating (at least I hope so...:-)=20

=20

And thanks again to all that have helped me and hopefully others along =
the way. All this have lead to some cleaning up in the CVS repository =
to. And the units for use in EMC 2 (I look forward to test it!!) have =
been questioned and hopefully dealt with in a good way.=20

=20

It would have been completely impossible for me to get it up without =
your help!

=20

Anders

Re: [Emc-users] Several Questions

[Jonathan Stark <emc@st...>]

Quoting jmkasunich@... (jmkasunich@...):
> Jonathan Stark wrote:
> So in other words, you are using a pic and a serial port to provide
> more digital I/O bits, with the understanding that those bits won't
> be particularly fast.  Not fast enough for step and direction pulses,
> that is - but plenty fast for lube, spindle start/stop, and things
> like that.

Presently, yes.  But, at the speeds attainable with a cheap pic
and the serial port (115200 or 230400 bps), you can get 10-20khz,
which... strangely enough... is very much in the range of where
I've heard people here talking about needing step and direction
to go.  And, rtai of course has real time serial drivers.

Add to that the fact that the PIC has enough brains that you
can tell *it* to handle the timing critical part, and things
get really interesting.

My first attempt for control was through serial, and I got great
results writing my own code for it, without using any realtime
support at all.  But I only need around 1khz to do what I've
done so far.  Unfortunatley, I wanted to use EMC's gcode
interpreter, and because of afore mentioned compile situations,
I wasn't comfortable adapting EMC to a serial interface.  So,
I have the PIC emulating a parallel interface for EMC, and
I talk to it through the serial port.

> This is a natural for the HAL - the HAL philosophy is that EMC itself
> should never access real I/O devices - it only touches HAL signals/pins.
> Then drivers transfer stuff from the HAL signals to real-world I/O.

This is a great step forward.   I just wish it was plugged into emc,
or that emc2 was far enough along to be useful for me now ;)

A slightly larger amount of structure, however, such that things
like step and direction could be combined and rewritten like that
fellow who had a step ccw and step cw signal rather than seperate step
and direction signals would be great.

So, a lego brick sort of thing where step/dir gets put in as
inputs, and outputs of that module are CCW step and CW step which
could then be piped through HAL would be cool.

Jonathan