Re: Learning BDI Emc - Outputs




Jack

Thanks for the confirmation that IO_Show is doing what is says.  With your 
systematic level of study of the system would you be willing to work your 
notes into a write up for the handbook? (other comments mixed in)

On Saturday 05 January 2002 08:23 pm, Jack wrote:
> Using BDI 2.04 I ran ./emc.run and was familiarizing myself with its
> operation which I thought I was beginning to understand untill I ran
> into this problem.
>
> I verifed the outputs using IO_Show and to be sure, I connected a
> voltmeter to the parallel port to check it out.  The voltmeter
> confirmed the IO_Show indications.
>
> Using the jog controls I could toggle the dir signal.  Then I found
> that when I  hit "Home", although the position indicators went to
> zero, there was no output on the parallel port.
>
> If this is the way that EMC is supposed to operate, then shouldn't
> the "Home" label be known by something else  -  such as "Reset
> Position Indicators" or does Home really mean a command to the table
> to go to its home position?

Unless you have real limit switches attached to the parport and the polarity 
set to look for real switches, the EMC finds that pin set for a logical home 
wherever the axis is.  The way I have them defined in mini.ini they do work 
like reset position.

> If the latter is the case then how come there is no output on the
> parallel port when this command is issued?  I would expect that the
> output just to start going until it reached a program limit.

If you change the polarity of the home switch pin, it will do exactly what 
you are suggesting that it should.  If you use the stg or ppmc definitions it 
will not only look for the home switch but a z index pulse as well.

> Please understand I'm trying to learn the system.
>
> So, next I decided to try doing some editing to the emc.run and
> emc.ini.
>
> I first did
> cp emc.run emcbp.run
> cp emc.ini emcbp.run
>
> Then I edited emcbp.run and changed the line
> from INIFILE=emc.run
> to INIFILE= emcbp.run

This is good!  Some are inclined to edit the emc.run and emc.ini directly and 
then they loose the originals.

> Then I ran
> ./emcbp.run
> F1, F2
> and hit Home to home X, the computer locks up (lost keyboard and
> mouse control) so had to hit the computer reset switch.

As Bill said, there is a problem In BDI 2.04.  We did not find it until that 
version had been published.  There is or should be some helpful info on the 
linuxcnc.org bdi, faq, and handbook pages.  

Freqmod is less likely to do it than steppermod.  Or upgrading to the 10/21 
stuff in the linuxcnc.org/dropbox has a fix for this problem but there have 
been suggestions that there may be a few other bugs in that one as well but 
it will not lock up your pc.  This problem varies a lot from pc to pc.

I don't know if I was the first to begin seeing the lockup problem but it 
plagued me for more than a year! It existed for me all the way from RedHat 
5.0 to Mandrake 7.2.  It was annoying enough that by the time we had tracked 
it down, I was almost ready to ressurect softwares from that other company or 
start buying proprietary CNC systems again.<g>

This comment is not meant to detract from the NIST work or that of Paul with 
the BDI. If you look back on the history of bug hunting in this code you can 
see that as soon as a bug gets defined and evidence points to a specific part 
of the system, the bug gets found and fixed rather quickly.  I think the 
shortest time I've seen was a report of a NAN (Not A Number).  It was made by 
Ian and within four hours Will and Fred had found and fixed it.  BTW a NAN 
had the interesting habit of sending the affected axis off toward infinity as 
quickly as possible!  This problem found its way into several real machines!

Every time I look at my copy of the sourceforge repository I am reminded of 
the complexity of the system.  We are dealing in something like 2000 source 
files and about 14 mb of code.  The doxygen references to the C and C++ parts 
of it, stored on linuxcnc.org/handbook, run to 50mb of html.  

> Under the header in the emc.run I noticed the line
> #Touch the file .debug_scripts in your home directory if you like
> #to see all your commands echoed.
>
> I did this and after rebooting I looked at that file and it held
> nothing.

My habit is to set the debug variable in the ini file to the maximum value, 
start the emc from a terminal rather than from the desktop icon, and study 
the commands and how they echo through the system's components.  Sometimes I 
have been known to highlight a block of the terminal output and copy to 
kwrite so that I can compare one run with another.  

> Question is, how do I overcome the lockup problem?

Oops.  Answered this before all the philosophy stuff above.  Hope this helps.

Ray




Date Index | Thread Index | Back to archive index | Back to Mailing List Page

Problems or questions? Contact