[Emc-users] Compiling with BDI-4.20

[Oscar Dalem]

Hi all,

I'm currently running off a BDI-4.20 installation and have completed the
steps described in "BDI-4 Install" on the Wiki pages to create the
required development environment. I'm currently endeavoring to extract
and compile a current version of emc with the latest changes to tp.c etc.

The command:

cvs -d:pserver:***@cvs.sourceforge.net:/cvsroot/emc checkout -Pr bdi-4 -d emc emc2

Does not seem to yield a complete file set.

However

cvs -d:pserver:***@cvs.sourceforge.net:/cvsroot/emc checkout -Pr
bdi-4.20 -d emc emc2

Does pull in a complete and compilable set of files but without the latest patches.

In looking at the Compile Farm entry for what I'm trying to build: EMC2:
BDI-4 Branch Slot 5, the table entry indicates that the build "PASSED"
but when you look at the log file behind it, it actually failed with the
same errors that I'm getting.

Any insight into what's going on would be appreciated.

Thank you in advance.

Oscar

[j***@att.net]

Post by Oscar Dalem
I'm currently running off a BDI-4.20 installation and have completed the
steps described in "BDI-4 Install" on the Wiki pages to create the
required development environment. I'm currently endeavoring to extract
and compile a current version of emc with the latest changes to tp.c etc.
emc emc2
Does not seem to yield a complete file set.
However
bdi-4.20 -d emc emc2
Does pull in a complete and compilable set of files but without the latest
patches.
BDI-4 Branch Slot 5, the table entry indicates that the build "PASSED"
but when you look at the log file behind it, it actually failed with the
same errors that I'm getting.

I just updated the compile farm scripts, so they correctly report FAILED.

Post by Oscar Dalem
Any insight into what's going on would be appreciated.

The compile farm is using the first checkout command:
cvs -d:{blahblah}:/cvsroot/emc checkout -Pr bdi-4 -d emc emc2

The error message generated by the farm comes from an older configure
script, that still thinks it is in the top level directory instead of
the src/ directory. I did a checkout on my development box and made
that change, and configure worked. But the make failed miserably,
with many, many missing files. It seems like the version marked
with the bdi-4 tag is really messed up, perhaps something went bad
during the merge with the head of CVS.

I was unaware of the existance of the bdi-4_20 tag, but as you say
it does compile. I don't know if it is intended to supersede the
original bdi-4 tag or not. Paul Corner is the guy to ask about
the bdi-4 variations. Here goes:

Hey Paul:

Should I remove the original bdi-4 from the compile farm? Should
I replace it with bdi-4_20 or some other tag, or should I just forget
about the bdi-4 branch as far as the compile farm goes?

Regards,

John Kasunich

[Tim & Heather Smith]

Hi All,

I was browsing the "developers list" today, and found the thread on the
"parport" reseting overnight, and causing the Pico Systems cards to fault.

This sounds like the problem I had a while back. I had put it down to a
power flicker.
I bought myself a UPS to supply the PC, but it didn't help.
I hadn't done anymore with it since then.

Assuming this is the same problem I tried the fix Jon put in his mail
(see bottom of this email)
However I can't find the file " /etc/modutils.arch/i386" on my
BDI2.20b system.
Does anyone know if this file resides somewhere else on the RedHat 6.2
system, or is there another similar file on this system that can be
edited.

Thanks in advance.

Tim Smith




1. edit the file
/etc/modutils.arch/i386
Comment out the line that says :
alias parport_lowlevel parport_pc
and add this line :
alias parport_pc off
save the file.

2. run this command :
update-modules

[paul_c]

Hi Tim

Post by Tim & Heather Smith
I was browsing the "developers list" today, and found the thread on the
"parport" reseting overnight, and causing the Pico Systems cards to fault.
This sounds like the problem I had a while back. I had put it down to a
power flicker.
I bought myself a UPS to supply the PC, but it didn't help.
I hadn't done anymore with it since then.
Assuming this is the same problem I tried the fix Jon put in his mail
(see bottom of this email)
 However I can't find the file " /etc/modutils.arch/i386" on my  
BDI2.20b system.
Does anyone know if this file resides somewhere else on the RedHat 6.2
system, or is there another  similar  file on this system that can be
edited.

For Redhat 6.x based systems such as BDI-2.20, look in /etc/conf.modules.


Regards, Paul.

[Tim & Heather Smith]

Thanks Paul,

I found and edited the file OK, but now I find the command
"update-modules" doesn't appear to exist.
Do you know what the equivalent in RH6.2 is?

I did a search on "update*" and got the following files,
/sbin/update
/usr/bin/updatedb

I tried running /bin/update, but don't know if it did anything.

Regards
Tim

Post by paul_c
For Redhat 6.x based systems such as BDI-2.20, look in /etc/conf.modules.
Regards, Paul.

[paul_c]

Hi Tim

Post by Tim & Heather Smith
I found and edited the file OK, but now I find the command
"update-modules" doesn't appear to exist.
Do you know what the equivalent in RH6.2 is?

Quoting from the Debian man page for update-modules.. "update-modules is an
obsolete command. In it's current form it will
execute /sbin/update-modules.modutils (the old update-modules program
provided by the modutils package) if it exists and do nothing else."

Redhat 6.x systems probably lack this command in preference to the root user
maintaining conf.modules directly.

Post by Tim & Heather Smith
I did a search on "update*" and got the following files,
/sbin/update
/usr/bin/updatedb
I tried running /bin/update, but don't know if it did anything.

"man update" will tell you what the command should do..
Running updatedb on a regular basis is not a bad idea as it speeds up the
command "locate" when searching for a file.


Regards, Paul.

[Tim & Heather Smith]

Thanks again Paul.
Regards
Tim

Post by paul_c
Quoting from the Debian man page for update-modules.. "update-modules is an
obsolete command. In it's current form it will
execute /sbin/update-modules.modutils (the old update-modules program
provided by the modutils package) if it exists and do nothing else."
Redhat 6.x systems probably lack this command in preference to the root user
maintaining conf.modules directly.

Post by Tim & Heather Smith
I did a search on "update*" and got the following files,
/sbin/update
/usr/bin/updatedb
I tried running /bin/update, but don't know if it did anything.

"man update" will tell you what the command should do..
Running updatedb on a regular basis is not a bad idea as it speeds up the
command "locate" when searching for a file.
Regards, Paul.

[paul_c]

Hi John

Post by j***@att.net
I was unaware of the existance of the bdi-4_20 tag, but as you say
it does compile.  I don't know if it is intended to supersede the
original bdi-4 tag or not.

The bdi-4_20 tag is just that - A tag to indicate the point at which the
version of emc on the BDI-4.20 release was built from. It is not, nor was it
ever intended to be, a branch point.

Post by j***@att.net
Should I remove the original bdi-4 from the compile farm?  Should
I replace it with bdi-4_20 or some other tag, or should I just forget
about the bdi-4 branch as far as the compile farm goes?

That is entirely up to you - It had been mandated that the bdi-4 branch would
be depreciated in favour of emc2 HEAD. It has served it purpose as a proving
ground for 2.6 builds and acting as a springboard for compiling emc2 with the
latest kernels.


Regards, Paul.

[Oscar Dalem]

Thanks to both John and Paul for your responses, but I still don't get it.

Is it no longer possible to extract and build a current version of emc
on a 2.6 distro?
or
To say it another way, if one were to build a 4.21 BDI tomorrow, what
cvs command would one issue to extract a buildable file set?

I apologize for being so dense, but I fear my decode ring is missing an
entry.

Thanks

Oscar

Post by paul_c
Hi John

Post by j***@att.net
I was unaware of the existance of the bdi-4_20 tag, but as you say
it does compile. I don't know if it is intended to supersede the
original bdi-4 tag or not.

The bdi-4_20 tag is just that - A tag to indicate the point at which the
version of emc on the BDI-4.20 release was built from. It is not, nor was it
ever intended to be, a branch point.

Post by j***@att.net
Should I remove the original bdi-4 from the compile farm? Should
I replace it with bdi-4_20 or some other tag, or should I just forget
about the bdi-4 branch as far as the compile farm goes?

That is entirely up to you - It had been mandated that the bdi-4 branch would
be depreciated in favour of emc2 HEAD. It has served it purpose as a proving
ground for 2.6 builds and acting as a springboard for compiling emc2 with the
latest kernels.
Regards, Paul.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[j***@att.net]

Post by Oscar Dalem
Thanks to both John and Paul for your responses, but I still don't get it.
Is it no longer possible to extract and build a current version of emc
on a 2.6 distro?
or
To say it another way, if one were to build a 4.21 BDI tomorrow, what
cvs command would one issue to extract a buildable file set?
I apologize for being so dense, but I fear my decode ring is missing an
entry.

That's understandable, it is a little complicated. Let's see if I can
clear things up a little (or maybe make it worse).

In the beginning there was EMC. I now prefer to call it EMC1 to
avoid confusion. EMC1 is pretty stable and supports a rather wide
range of IO devices. However, it does not compile on system with
kernel 2.6, and is getting no further development except for some
minor bugfixes.

Then there was EMC2. It has been functional for not quite a year,
but is still experimental. At present the IO device support is
limited. Software step/dir works fine, but drivers for other
hardware are in various stages of completion. (Vital Systems
MOTENC works, Servo-to-Go is nearly done, PPMC under construction,
etc, etc.) EMC2 works on kernels from 2.2 thru 2.6, and is
intended to be the path for future development. It uses the RTAPI
low level interface to the realtime OS, and it uses HAL to manage
I/O devices and other low-level interconnection between various
modules. It also uses libnml, a lighter and cleaner library that
replaces the former RCSLIB. (RCSLIB is a stand-alone library
that needed to be compiled before EMC proper, libnml is integrated
into the EMC2 source tree).

In the middle is the BDI-4 branch. It is a cross between EMC1 and
EMC2. Structurally, it is mostly EMC1, it doesn't use RTAPI or HAL.
However it does use libnml, and has been converted to compile on a
kernel 2.6 system (specifically the Debian system that is the BDI-4.20
iso). It is stable and production ready, just like EMC1. Also like
EMC1, it will get no future development. It was released to serve a
specific need that couldn't wait for EMC2, but needed to work with
kernel 2.6 and therefore couldn't use EMC1 either.

When you install the BDI-4.20, you get a pre-compiled and installed
copy of the BDI-4 version of EMC. I believe the bdi-4_20 CVS tag
(snapshot) is exactly what ships on the BDI-4.20 iso. At this point
I'm not clear about the status of the associated branch. At one point
I thought bugfixes like the recent tp fix could be applied to the
branch and used to update people who are using the bdi-4_20 snapshot,
but that no longer appears to be true. However, I expect that the
next BDI (BDI-4.23?) will have a version of the bdi-4 branch that
includes the tp fix. (Paul, please correct me if this is wrong.)

Summary:

EMC1 - compiles on older BDI's and other systems using 2.2 and 2.4
kernels. Stable and usable for production on a wide variety of
machines. No future development except minor bugfixes. Not
usable on BDI-4 computers, or any computer running a 2.6 kernel.

bdi-4_20 tag - compiles only on BDI-4 systems (and maybe other
kernel 2.6 systems, but you're on your own). Stable and usable
for production. No future development or bugfixes, it is a
single snapshot. BDI-4.23 _may_ provide an upgrade path.

EMC2 - compiles on all BDI's, and on other systems using a
range of kernels (but can be tricky on non-BDI systems). Should
be considered experimental, but is reasonably stable for non-
critical production work. Intended to be the path for future
development.

NOTE that there is a critical distinction between the bdi-4_20
version of EMC itself, and the BDI-4.20 distribution. The distro
gives you a complete Debian based system with a realtime kernel
and a particular snapshot of EMC. Although that snapshot is
somewhat "frozen in time", you can download and compile the
latest version of EMC2 at any time. The original bdi-4_20
snapshot remains installed, and you can run it, or EMC2,
depending on your needs.

If you want to build EMC2 on a BDI-4.20 system, there is a
wiki page with specific instructions:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BDI-4_Compile_EMC2

Regards,

John Kasunich

[Oscar Dalem]

Thanks John (again)

I'd browsed the cvs tree long enough to be fairly certain that the
answer wasn't obvious (egg is the hardest stain to remove), but I
thought that I just wasn't asking the right question. I'd hadn't really
considered that there might not be any (automatic) way of doing it.

In any case I appreciate the explanation. I'm sure that there are a
number of us out here in the bleachers that will find it helpful as
well. In the interim, I've successfully extracted and compiled emc2
looks like that's the place to be. There's nothing like another learning
opportunity.

Thanks again,

Oscar

Post by j***@att.net

Post by Oscar Dalem
Thanks to both John and Paul for your responses, but I still don't get it.
Is it no longer possible to extract and build a current version of emc
on a 2.6 distro?
or
To say it another way, if one were to build a 4.21 BDI tomorrow, what
cvs command would one issue to extract a buildable file set?
I apologize for being so dense, but I fear my decode ring is missing an
entry.

That's understandable, it is a little complicated. Let's see if I can
clear things up a little (or maybe make it worse).
In the beginning there was EMC. I now prefer to call it EMC1 to
avoid confusion. EMC1 is pretty stable and supports a rather wide
range of IO devices. However, it does not compile on system with
kernel 2.6, and is getting no further development except for some
minor bugfixes.
Then there was EMC2. It has been functional for not quite a year,
but is still experimental. At present the IO device support is
limited. Software step/dir works fine, but drivers for other
hardware are in various stages of completion. (Vital Systems
MOTENC works, Servo-to-Go is nearly done, PPMC under construction,
etc, etc.) EMC2 works on kernels from 2.2 thru 2.6, and is
intended to be the path for future development. It uses the RTAPI
low level interface to the realtime OS, and it uses HAL to manage
I/O devices and other low-level interconnection between various
modules. It also uses libnml, a lighter and cleaner library that
replaces the former RCSLIB. (RCSLIB is a stand-alone library
that needed to be compiled before EMC proper, libnml is integrated
into the EMC2 source tree).
In the middle is the BDI-4 branch. It is a cross between EMC1 and
EMC2. Structurally, it is mostly EMC1, it doesn't use RTAPI or HAL.
However it does use libnml, and has been converted to compile on a
kernel 2.6 system (specifically the Debian system that is the BDI-4.20
iso). It is stable and production ready, just like EMC1. Also like
EMC1, it will get no future development. It was released to serve a
specific need that couldn't wait for EMC2, but needed to work with
kernel 2.6 and therefore couldn't use EMC1 either.
When you install the BDI-4.20, you get a pre-compiled and installed
copy of the BDI-4 version of EMC. I believe the bdi-4_20 CVS tag
(snapshot) is exactly what ships on the BDI-4.20 iso. At this point
I'm not clear about the status of the associated branch. At one point
I thought bugfixes like the recent tp fix could be applied to the
branch and used to update people who are using the bdi-4_20 snapshot,
but that no longer appears to be true. However, I expect that the
next BDI (BDI-4.23?) will have a version of the bdi-4 branch that
includes the tp fix. (Paul, please correct me if this is wrong.)
EMC1 - compiles on older BDI's and other systems using 2.2 and 2.4
kernels. Stable and usable for production on a wide variety of
machines. No future development except minor bugfixes. Not
usable on BDI-4 computers, or any computer running a 2.6 kernel.
bdi-4_20 tag - compiles only on BDI-4 systems (and maybe other
kernel 2.6 systems, but you're on your own). Stable and usable
for production. No future development or bugfixes, it is a
single snapshot. BDI-4.23 _may_ provide an upgrade path.
EMC2 - compiles on all BDI's, and on other systems using a
range of kernels (but can be tricky on non-BDI systems). Should
be considered experimental, but is reasonably stable for non-
critical production work. Intended to be the path for future
development.
NOTE that there is a critical distinction between the bdi-4_20
version of EMC itself, and the BDI-4.20 distribution. The distro
gives you a complete Debian based system with a realtime kernel
and a particular snapshot of EMC. Although that snapshot is
somewhat "frozen in time", you can download and compile the
latest version of EMC2 at any time. The original bdi-4_20
snapshot remains installed, and you can run it, or EMC2,
depending on your needs.
If you want to build EMC2 on a BDI-4.20 system, there is a
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BDI-4_Compile_EMC2
Regards,
John Kasunich
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[paul_c]

Let me throw in a few comments just to stir things up a bit..

Post by j***@att.net
In the beginning there was EMC. I now prefer to call it EMC1 to
avoid confusion. EMC1 is pretty stable and supports a rather wide
range of IO devices. However, it does not compile on system with
kernel 2.6, and is getting no further development except for some
minor bugfixes.

"is getting no further development" is not quite correct as far as HEAD is
concerned. Keith Rumley is (has ?) in the process of making changes to the
interpreter with a number of undocumented "features" - Work that should be
taking place in a branch (in my opinion). In the meantime, Chris Radeck is
maintaining a stable branch consisting of proven bug fixes. This *should* be
work conducted on the main branch..

Post by j***@att.net
Then there was EMC2. It has been functional for not quite a year,
but is still experimental.

Much of the core emc/ source code (not hal/ or rtapi/) has a great deal in
common with EMC1 code - In time, the code base will probably evolve and much
of the commonality will disappear...

Post by j***@att.net
In the middle is the BDI-4 branch. It is a cross between EMC1 and
EMC2. Structurally, it is mostly EMC1, it doesn't use RTAPI or HAL.
However it does use libnml, and has been converted to compile on a
kernel 2.6 system (specifically the Debian system that is the BDI-4.20
iso). It is stable and production ready, just like EMC1. Also like
EMC1, it will get no future development. It was released to serve a
specific need that couldn't wait for EMC2, but needed to work with
kernel 2.6 and therefore couldn't use EMC1 either.

In between the original BDI-4.04 release and the latest BDI-4.23, much of the
work on libnml and some of the user space code has been merged in to and from
the emc2 trunk. The interpreter recieved a workover which was used initially
in the bdi-4 branch, and then merged in to the main emc2 trunk. Make and
configure are also a direct decendant of EMC2, although the bdi-4 branch
layed the groundwork for kbuild support for EMC2 - The main point of
divergance is in the realtime code and hardware drivers.

Post by j***@att.net
When you install the BDI-4.20, you get a pre-compiled and installed
copy of the BDI-4 version of EMC. I believe the bdi-4_20 CVS tag
(snapshot) is exactly what ships on the BDI-4.20 iso.

Indeed, the whole purpose of the bdi-4.20 tag is to mark a point at which the
ISO was built from. There are also a few bdi-rcxx and bdi-2.xx tags in the
main EMC1 tree for older builds.

Post by j***@att.net
At this point I'm not clear about the status of the associated branch. At
one point I thought bugfixes like the recent tp fix could be applied to the
branch and used to update people who are using the bdi-4_20 snapshot,
but that no longer appears to be true. However, I expect that the
next BDI (BDI-4.23?) will have a version of the bdi-4 branch that
includes the tp fix. (Paul, please correct me if this is wrong.)

Bug fixes for the trajectory planner were tested on a BDI-4 build first, as
were several others that have since been merged in to EMC2. These, along with
recent changes to configure and libnml will be used in the BDI-4.23 release.

Post by j***@att.net
EMC1 - compiles on older BDI's and other systems using 2.2 and 2.4
kernels. Stable and usable for production on a wide variety of
machines. No future development except minor bugfixes. Not
usable on BDI-4 computers, or any computer running a 2.6 kernel.

See comments above regarding development. Should it be pointed out that the
nonrealtime code will compile on a 2.6 kernel and allow you to run the
simulator ? - Otherwise, correct about building on a realtime 2.6 kernel.

Post by j***@att.net
bdi-4_20 tag - compiles only on BDI-4 systems (and maybe other
kernel 2.6 systems, but you're on your own). Stable and usable
for production. No future development or bugfixes, it is a
single snapshot. BDI-4.23 _may_ provide an upgrade path.

It should compile on any 2.6 kernel patched with RTAI (excluding fusion).
The bdi-4.23 tag may indeed provide one final upgrade.

Post by j***@att.net
EMC2 - compiles on all BDI's, and on other systems using a
range of kernels (but can be tricky on non-BDI systems). Should
be considered experimental, but is reasonably stable for non-
critical production work. Intended to be the path for future
development.

If compilation on a non-BDI system is difficult, then something is wrong with
autoconfigure - The primary goal of using the GNU autotools was to eliminate
such issues.


Regards, Paul.

[Tim & Heather Smith]

Today I downloaded the latest BDI 4.23.

A huge thanks to Paul (and anyone/everyone else involved), for getting
this available.

I have been waiting for this one for a while now, as I have 2 x PC's
with the i810 chipset (didn't realize the problems they had).
I been running BDI 2.20b with Jon's USC on one of these boxes for quite
a while, but have been wanting to upgrade and been unable.

The install wasn't smooth but it's up and running now (On my spare PC).
The few glitches, which I'll list in case it helps someone else were:-

1. I had to use the text install as the screen went "nuts" when the
Xserver started.

2. I have dual booted all my PC's so far, but when I set partitions up
with a couple of dos partitions, something went wrong and the install
failed to proceed.
I tried this a couple of times with no success.
When I tried the 3rd time, I still prepared the install as a dual boot,
but didn't set up the dos partitions (I have since done this manually,
and they work fine) and the install went ahead.

3. After the install had done it's business, it was waiting to set up
the video card etc, however the keyboard was all "messed up".
The "tab" key would not cycle through the options, the main "enter" key
did this, and the second "enter" key on the RHS selected the choices.
(strange??)

After I got through all that, everything seems fine.

All I want to do now is see if I can set it up so it will read my USB stick.
Is this a simple thing? I've only had a quick look around the help file
but I haven't found anything yet.

I'm not about to upgrade my machine PC yet.
Not until I've proved to myself that this works on the spare box, but it
all looks pretty good so far.

Thanks again

Tim




Thanks again

[paul_c]

Hi Tim

Post by Tim & Heather Smith
Today I downloaded the latest BDI 4.23.

Drat.. Hadn't even announced it's release.. (was waiting for the other servers
to update first.)

Post by Tim & Heather Smith
I have been waiting for this one for a while now, as I have 2 x PC's
with the i810 chipset (didn't realize the problems they had).

Most graphics chipsets that share main memory are problematic. Not having
access to an i810 box myself, I can not test.

Post by Tim & Heather Smith
The install wasn't smooth but it's up and running now (On my spare PC).
The few glitches, which I'll list in case it helps someone else were:-
1. I had to use the text install as the screen went "nuts" when the
Xserver started.

I wonder if "linux noprobe" at the initial splash screen would work..

Post by Tim & Heather Smith
2. I have dual booted all my PC's so far, but when I set partitions up
with a couple of dos partitions, something went wrong and the install
failed to proceed.
I tried this a couple of times with no success.
When I tried the 3rd time, I still prepared the install as a dual boot,
but didn't set up the dos partitions (I have since done this manually,
and they work fine) and the install went ahead.

If you want to install dos on the same machine, you are better off installing
that first and then moving on to a linux install - M$ makes the assumption
that it is the only operating system and will trash the MBR for you.

Post by Tim & Heather Smith
3. After the install had done it's business, it was waiting to set up
the video card etc, however the keyboard was all "messed up".
The "tab" key would not cycle through the options, the main "enter" key
did this, and the second "enter" key on the RHS selected the choices.
(strange??)

Known problem - Text install has a bug or two in it.

Post by Tim & Heather Smith
All I want to do now is see if I can set it up so it will read my USB
stick. Is this a simple thing? I've only had a quick look around the help
file but I haven't found anything yet.

If a USB memory stick is anything like a USB Zip drive I set up for someone,
it will be easy. Load the usb storage modules, plug the stick in, and mount
it. If you want to get fancy, setting up a desktop icon to access the device
is a trivial exercise in click'n'shoot.


Regards, Paul.

[Bob Simcoe]

Had a working 4.2 -- tried installing 4.23 and found it was missing a
library LBTK 8.4. The linux seems much better and faster, but cannot start
EMC.

Checked the MD5 checksum before installing and it was fine.

[paul_c]

Post by Bob Simcoe
Had a working 4.2 -- tried installing 4.23 and found it was missing a
library LBTK 8.4.  The linux seems much better and faster, but cannot start
EMC.

Hi Bob

Install tk8.4-dev as a workround - Will have an updated & fixed build in a day
or two.

Regards, Paul.

[Tim & Heather Smith]

I've got the BDI 4.23 installed on the actual PC I use on my mill (on a
spare partition, so I still have access to BDI 2.20b)
Also got the usb flash drive working.

What would be the best way to get the Pico Systems "Universal Stepper
Card" working ?

I had hoped that it may have been ready to go, but when I edited the ini
file to use univstepmod.o I received an error saying it couldn't find
the module.
(See bottom of post for actual error)

Is it not part of the BDI 4.23 build, or have I likely set something up
wrong ?

Another question, do you have to be logged in as root to use EMC?
I could get the "Sherline" versions running as root but not as a user.

Thanks again

Tim





localhost:~# cd /usr/local/emc
localhost:/usr/local/emc# ./emc.run
inivar = plat/nonrealtime/bin/inivar
INIFILE = emc.ini
RS274NGC_PARAMFILE = emc.var
starting emc...
Removing module univstepmod
ERROR: Module univstepmod does not exist in /proc/modules
starting EMC MOTION PROGRAM -- univstepmod.o...
modinfo: could not find module univstepmod.o
modinfo: could not find module univstepmod.o
modinfo: could not find module univstepmod.o
NUTS********************
modinfo: could not find module univstepmod.o
modinfo: could not find module univstepmod.o
modprobe univstepmod.o
FATAL: Module univstepmod.o not found.
can't install univstepmod.o
Removing module univstepmod
ERROR: Module univstepmod does not exist in /proc/modules
emc.ini was not changed.
emc.var was not changed.
localhost:/usr/local/emc#

[paul_c]

Hi Tim

Post by Tim & Heather Smith
I've got the BDI 4.23 installed on the actual PC I use on my mill (on a
spare partition, so I still have access to BDI 2.20b)
Also got the usb flash drive working.

Just as another release comes out.. The 4.24 build contains a couple of minor
bug fixes to EMC, i.e. Malte Rutemann's iosh patch, along with a fix for a
tk8.4 lib error - If you installed the development libraries and don't use
iosh for custom IO controllers, neither of these issues will affect you. See
the announcement for further details regarding BDI-4.24.

Post by Tim & Heather Smith
What would be the best way to get the Pico Systems "Universal Stepper
Card" working ?
I had hoped that it may have been ready to go, but when I edited the ini
file to use univstepmod.o I received an error saying it couldn't find
the module.
ERROR: Module univstepmod does not exist in /proc/modules
starting EMC MOTION PROGRAM -- univstepmod.o...
modinfo: could not find module univstepmod.o
modinfo: could not find module univstepmod.o
modinfo: could not find module univstepmod.o
NUTS********************
Is it not part of the BDI 4.23 build, or have I likely set something up
wrong ?

I bet you have a couple of lines in the EMCMOT section that read:

# Don't use an extension with the module name - The script works it out.
EMCMOT = univstepmod.o
# EMCMOT = freqmod


Simply remove the dot & o and after setting the EMCIO to ppmcbridgeportio you
should be good to go.

Post by Tim & Heather Smith
Another question, do you have to be logged in as root to use EMC?
I could get the "Sherline" versions running as root but not as a user.

Even when I started the BDI-2.xx series, i disliked the idea of having to run
EMC as root - Logging in as root makes it so easy to turn a simple mistake in
to a catastrophic disaster - rm -fR /* - Since BDI-2.xx development ceased,
sudo became widely available, this allows a logged in usr to run one or more
commands as root subject to the policy set out in /etc/sudoers. BDI-4.xx (and
BDI-Live) is fairly relaxed in that any command can be run as root by the
usr. It may be possible that the problem you are experiencing is down to the
tk8.4 error mentioned earlier.. In which case, after either opening a root
terminal or logging in as root, insert the BDI-4.23 CD in to the drive and
run the following two commands:

apt-cdrom add
apt-get install tk8.4-dev

Answer "y" when prompted and ignore any "W: Couldn't stat source package
list ..." warnings.


Regards, Paul.

[Tim & Heather Smith]

Post by paul_c
# Don't use an extension with the module name - The script works it out.
EMCMOT = univstepmod.o
# EMCMOT = freqmod

Thanks Paul,

You were correct, I hadn't read the line about not using extensions.

I'm still not up and running though.

It took me a while but I eventually figured out the the ppmcio
(bdi2.20b) has been renamed in the new bdi to ppmcbridgeportio, and now
that bit works.

The problem I have now is I can't get the motors to move.
I have set up the ini file as close as I can to the working ini file for
bdi 2.20.

When I start up EMC it obviously detects the USC card (EMC won't start
up if the USC is not present, if it is selected in the ini file).
The IO seems to work OK, as EMC detects the Estop circuit, and will also
start and stop the spindle OK.

If I move the Z axis by hand, EMC is reads the encoder fine and the
numbers change.
Note I only have an encoder hooked up to one axis at the moment, the
other 2 axes read the step pulses back into the card.

When I try and make a move on the z there is no movement at all, and I
get an immediate following error (because the encoder didn't move)
However if I try to move the other axes (which read back motors steps in
lieu of encoders), the numbers move, but there is still no movement from
the motors.

It's like the motor drivers are not enabled, but I can't find where to
change this.

I have tried the
ENABLE_POLARITY in the AXIS sections
SETUP and HOLD times (I think Jon has set these up for Geckos now)
with no luck.

This is definitely not a hardware problem as if I reboot the bdi2.20b it
all works fine.

Any thoughts on where I should look now ?

I have attached my ini file (in case someone has time to look at it).

Thanks again in advance.
Regards
Tim

[paul_c]

Hi Tim

Post by Tim & Heather Smith
When I try and make a move on the z there is no movement at all, and I
get an immediate following error (because the encoder didn't move)
However if I try to move the other axes (which read back motors steps in
lieu of encoders), the numbers move, but there is still no movement from
the motors.
It's like the motor drivers are not enabled, but I can't find where to
change this.

At a guess, it sounds like the enable polarity needs to be inverted. Under
each [AXIS_n] section, look for ENABLE_POLARITY, if it is 0, change it to 1
(or 1 to 0).


Regards, Paul.

[Tim & Heather Smith]

Post by paul_c
At a guess, it sounds like the enable polarity needs to be inverted. Under
each [AXIS_n] section, look for ENABLE_POLARITY, if it is 0, change it to 1
(or 1 to 0).

Hi Paul,

I've tried the enables in both states, with no success.
I'm at a bit of a loss, as that seemed the obvious thing to try.

Regards
Tim

[Jon Elson]

Post by Tim & Heather Smith

Post by paul_c
At a guess, it sounds like the enable polarity needs to be inverted.
Under each [AXIS_n] section, look for ENABLE_POLARITY, if it is 0,
change it to 1 (or 1 to 0).

Hi Paul,
I've tried the enables in both states, with no success.
I'm at a bit of a loss, as that seemed the obvious thing to try.

The axis enable polarity is a historical EMC function that goes
nowhere with any Pico Systems interface, as there are no digital
output terminals associated with it.

The only enable output available is SSR8, which is hard-wired
to turn on when out of E-stop. If you have an SSR there, then it
should turn on, and its LED should light up. If you don't have
a SSR there, put a 510 or 1K Ohm resistor across the two
closest terminals of the SSR location, and it will enable the
LED. If that LED does not light, the board is still in E-stop
for some reason, and you will get no step or other outputs.
Note that the USC requires that several of the parameters in the
[EMCIO] section be set specifically or this board. These are :
ESTOP_SENSE_INDEX = 14
ESTOP_SENSE_POLARITY = 0
ESTOP_WRITE_INDEX = 7
ESTOP_WRITE_POLARITY = 0

If any of these are not set this way, the board will not come out of
estop. Also, if any other xxx_WRITE_INDEX is set to 7, it could
override the ESTOP_WRITE_INDEX, so make sure that no other
write index is set to 7.


If the LED DOES light up, then the problem is something having to
do with getting the velocity command out to the step generator.
I'm not sure why there should be a problem with this. Does
the following error happen at all velocities? Try a jog at extremely
slow speed, like 1 IPM and 10% feed override, and see if it still
happens.

Jon

[Tim & Heather Smith]

Hi Jon,

I put a resistor in the SSR8 as you suggested.
The card is coming out of Estop.
(i.e. Once EMC starts and then the F1 key is pressed, the LED does light
up.)
I also tried jogging at low speed, it still causes a following error,
but it took a while to happen.
Note this only happens on the axis with the encoder fitted.

The other axes appear to move on the screen but the motors do not.
This seems a bit odd, as for the axes that do not have encoders, EMC
must be reading the step pulses from the USC card as encoder pulses for
the axis positions to change. Yet there are no step pulses being output
from the card (at least none that the geckos pick up), so how can the
positions on the screen change?

Just wondering if the Setup and Hold values could be affecting this.
What values would you recommend for Gecko 201's?

Regards
Tim

Post by Jon Elson
The only enable output available is SSR8, which is hard-wired
to turn on when out of E-stop. If you have an SSR there, then it
should turn on, and its LED should light up. If you don't have
a SSR there, put a 510 or 1K Ohm resistor across the two
closest terminals of the SSR location, and it will enable the
LED. If that LED does not light, the board is still in E-stop
for some reason, and you will get no step or other outputs.
Note that the USC requires that several of the parameters in the
ESTOP_SENSE_INDEX = 14
ESTOP_SENSE_POLARITY = 0
ESTOP_WRITE_INDEX = 7
ESTOP_WRITE_POLARITY = 0
If any of these are not set this way, the board will not come out of
estop. Also, if any other xxx_WRITE_INDEX is set to 7, it could
override the ESTOP_WRITE_INDEX, so make sure that no other
write index is set to 7.
If the LED DOES light up, then the problem is something having to
do with getting the velocity command out to the step generator.
I'm not sure why there should be a problem with this. Does
the following error happen at all velocities? Try a jog at extremely
slow speed, like 1 IPM and 10% feed override, and see if it still
happens.
Jon

[Jon Elson]

Post by Tim & Heather Smith
Hi Jon,
I put a resistor in the SSR8 as you suggested.
The card is coming out of Estop.
(i.e. Once EMC starts and then the F1 key is pressed, the LED does
light up.)
I also tried jogging at low speed, it still causes a following error,
but it took a while to happen.
Note this only happens on the axis with the encoder fitted.

That would be normal when the axis is not moving. Is this axis also a
Gecko 201?

Post by Tim & Heather Smith
The other axes appear to move on the screen but the motors do not.
This seems a bit odd, as for the axes that do not have encoders, EMC
must be reading the step pulses from the USC card as encoder pulses
for the axis positions to change. Yet there are no step pulses being
output from the card (at least none that the geckos pick up), so how
can the positions on the screen change?
Just wondering if the Setup and Hold values could be affecting this.
What values would you recommend for Gecko 201's?

Yes. I would recommend that hold time be set to 4.0 (4 uS)
and that setup time be set to 10.0 (10 uS). I don't know quite what
happens if you have no parameter in the [AXIS_0] section, I don't
think there is an automatic default applied anywhere. So, these
setings may get randomly assigned if you don't do it explicitly.
If you are not pushing the drive to the top of its frequency range,
then you can make these values larger. (25.4 uS is the max value.)

The parameters in [AXIS_0] are the ones that matter, if any SETUP_TIME
or HOLD_TIME parameters are in other axis definitions, they are ignored.
(This is due to the hardware of the USC board, where these settings are
global to the whole board.)

Jon

[Matthew Glenn Shaver]

Post by Jon Elson
Yes. I would recommend that hold time be set to 4.0 (4 uS)
and that setup time be set to 10.0 (10 uS). I don't know quite what
happens if you have no parameter in the [AXIS_0] section, I don't
think there is an automatic default applied anywhere. So, these
setings may get randomly assigned if you don't do it explicitly.

Actually, the default setup time is 1, and the default hold time is 2
(from iniaxis.cc).

Matt

[Jon Elson]

Post by Matthew Glenn Shaver

Post by Jon Elson
Yes. I would recommend that hold time be set to 4.0 (4 uS)
and that setup time be set to 10.0 (10 uS). I don't know quite what
happens if you have no parameter in the [AXIS_0] section, I don't
think there is an automatic default applied anywhere. So, these
setings may get randomly assigned if you don't do it explicitly.

Actually, the default setup time is 1, and the default hold time is 2
(from iniaxis.cc).

Ah, that sounds like the problem, then. a 2 uS step pulse width is
likely to
be missed by the Gecko drives. I DO have these parameters described in my
writeup of the USC board and the ini file on the EMC wiki, but it is buried
under a lot of other important stuff.

Jon

[Tim & Heather Smith]

Post by Jon Elson

Post by Matthew Glenn Shaver

Post by Jon Elson
Yes. I would recommend that hold time be set to 4.0 (4 uS)
and that setup time be set to 10.0 (10 uS). I don't know quite what
happens if you have no parameter in the [AXIS_0] section, I don't
think there is an automatic default applied anywhere. So, these
setings may get randomly assigned if you don't do it explicitly.

Actually, the default setup time is 1, and the default hold time is 2
(from iniaxis.cc).

Ah, that sounds like the problem, then. a 2 uS step pulse width is
likely to
be missed by the Gecko drives. I DO have these parameters described in my
writeup of the USC board and the ini file on the EMC wiki, but it is buried
under a lot of other important stuff.
Jon

Unfortunately this hasn't worked either.......

Just to be sure there is no problem with my hardware I stated up
bdi2.20b (same pc dual booted), all worked perfectly.

The ini files of bdi 2.20b and 4.23 are as similar as they can be with
the exception of
univstepmod.o vs univstepmod
and
ppmcio vs ppmcbridgeportio

Regards
Tim

[paul_c]

Hi Tim

Post by Tim & Heather Smith
Just to be sure there is no problem with my hardware I stated up
bdi2.20b (same pc dual booted), all worked perfectly.
The ini files of bdi 2.20b and 4.23 are as similar as they can be with
the exception of univstepmod.o vs univstepmod and ppmcio vs
ppmcbridgeportio

Working through the same problem with Mikko Martsola yesterday, his system
apparently works with the latest BDI -4 without any serious problems. A
promise of the ini file along with a sample output from dmesg was given..
Hopefully, the details will be posted some time today..

In the meantime, could you post your unabridged ini file ?


Regards, Paul.

[Tim & Heather Smith]

Post by paul_c
Hi Tim

Post by Tim & Heather Smith
Just to be sure there is no problem with my hardware I stated up
bdi2.20b (same pc dual booted), all worked perfectly.
The ini files of bdi 2.20b and 4.23 are as similar as they can be with
the exception of univstepmod.o vs univstepmod and ppmcio vs
ppmcbridgeportio

Working through the same problem with Mikko Martsola yesterday, his system
apparently works with the latest BDI -4 without any serious problems. A
promise of the ini file along with a sample output from dmesg was given..
Hopefully, the details will be posted some time today..
In the meantime, could you post your unabridged ini file ?
Regards, Paul

Hi Paul,

I have attached the ini file I have been trying to use (emc.ini).
I have also attached the ini file I am using successfully with bdi 2.20b
(bdi2_20b_emc.ini) just in case it is any use.

Thanks for your help with this.

Regards
Tim

[Tim & Heather Smith]

Hi Paul/Jon,
I've done a little more investigating with the problem I have running
the USC card with BDI 4.23.

I connected my Oscilloscope to the Gecko 201's step and Direction pins.
The Direction signal is definitely getting to the drives, but the Step
signals are not. ( I confirmed I could actually measure these on the BDI
2.20b setup, and I was able to see the Steps OK).

I also ran EMC from a terminal window and noticed an error I have not
seen before.

"Can not find -sec EMCMOT -var PERIOD -num 1
PERIOD not found"

Could this be a pointer to what my problem is ?

See entire messages from the terminal window below.


Thanks again.

Tim



localhost:~# cd /usr/local/emc
localhost:/usr/local/emc# ./emc.run
inivar = plat/nonrealtime/bin/inivar
INIFILE = emc.ini
RS274NGC_PARAMFILE = emc.var
starting emc...
starting EMC MOTION PROGRAM -- univstepmod...
Can not find -sec EMCMOT -var PERIOD -num 1
PERIOD not found
IO_BASE_ADDRESS 0x378
modprobe univstepmod IO_BASE_ADDRESS=0x378 SHMEM_KEY=100
done
starting EMC IO PROGRAM -- ppmcbridgeportio...done
Version: 1.2
Machine: PPMC
iniFind is depreciated
pptDioInit in ppmcparport.c, emcmotIo struct at 0xB7CE1A48
starting EMC TASK PROGRAM -- bridgeporttask...done
Version: 1.2
Machine: PPMC
iniFind is depreciated
Issuing EMC_TRAJ_SET_TERM_COND -- (+222,+16, +0, +2,)
Issuing EMC_TRAJ_SET_ORIGIN -- (+224,+60,
+0,-1.225000,0.000000,0.000000,0.000000,0.000000,0.000000,)
running EMC DISPLAY PROGRAM -- tkemc...
emcStatus->motion.traj.mode = 1
Issuing EMC_TRAJ_SET_SCALE -- (+209,+20, +1,1.000000,)
Issuing EMC_TASK_SET_STATE -- (+505,+16, +2, +2,)
Issuing EMC_TASK_SET_STATE -- (+505,+16, +3, +4,)
iosh: no process killed
pptDioQuit in ppmcparport.c
emc.ini was not changed.
emc.var was not changed.
Removing kernel module rtai_shm and anything that depends on it.
Including univstepmod
Removing kernel module rtai_hal and anything that depends on it.
Including rtai_lxrt
Removing kernel module adeos
localhost:/usr/local/emc#

[paul_c]

Hi Tim

Post by Tim & Heather Smith
I've done a little more investigating with the problem I have running
the USC card with BDI 4.23.
I also ran EMC from a terminal window and noticed an error I have not
seen before.
"Can not find -sec EMCMOT -var PERIOD -num 1
PERIOD not found"

Ignore warnings about PERIOD - This parameter is only used by freqmod..

One thing I would be interested in is the output of dmesg after setting
SETUP_TIME = 0 in AXIS_1 section..


Regards, Paul.

[Tim & Heather Smith]

Post by paul_c
Ignore warnings about PERIOD - This parameter is only used by freqmod..
One thing I would be interested in is the output of dmesg after setting
SETUP_TIME = 0 in AXIS_1 section..
Regards, Paul.

Hi Paul,

I'm not sure of what dmesg actually is.
Is it the errors that appear when running EMC from a terminal window?
If that is the case the errors/messages that appear in the terminal
window, are exactly the same with the SETUP_TIME = 0.

Regards
Tim

[paul_c]

Hi Tim

Post by Tim & Heather Smith

Post by paul_c
One thing I would be interested in is the output of dmesg after setting
SETUP_TIME = 0 in AXIS_1 section..

I'm not sure of what dmesg actually is.

Typing in dmesg at the command line prompt returns all the messages sent out
by the kernel modules. Often when a module fails to load, looking at the
dmesg output reveals the reason for the failure.


Regards, Paul.

[Tim & Heather Smith]

Post by paul_c
Typing in dmesg at the command line prompt returns all the messages sent out
by the kernel modules. Often when a module fails to load, looking at the
dmesg output reveals the reason for the failure.
Regards, Paul.

Hi Paul,
I have got the dmesg output (unfortunately it is way over my head).
To get this I restarted the PC fired up EMC then closed it,
after that I ran dmesg the results are below.
BTW all instances of SET_UP and HOLD were set to 0 for this.

Regards

Tim

localhost:~# dmesg
Linux version 2.6.10-adeos (***@localhost.localdomain) (gcc version
2.95.4 20011002 (Debian prerelease)) #1 Sat Mar 5 22:56:08 GMT 2005
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000007ec0000 (usable)
BIOS-e820: 0000000007ec0000 - 0000000007ef8000 (ACPI data)
BIOS-e820: 0000000007ef8000 - 0000000007f00000 (ACPI NVS)
BIOS-e820: 00000000ffb80000 - 00000000ffc00000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
126MB LOWMEM available.
On node 0 totalpages: 32448
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 28352 pages, LIFO batch:6
HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
Built 1 zonelists
Kernel command line: root=/dev/hda6 ro splash=silent vga=788
bootsplash: silent mode.
Initializing CPU#0
Adeos 2.6r9c5/x86: Root domain Linux registered.
PID hash table entries: 512 (order: 9, 8192 bytes)
Detected 797.761 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 120596k/129792k available (2290k kernel code, 8640k reserved,
942k data, 216k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1585.15 BogoMIPS (lpj=792576)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0383f9ff 00000000 00000000 00000000
CPU: After vendor identify, caps: 0383f9ff 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040
CPU: Intel Pentium III (Coppermine) stepping 06
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
checking if image is initramfs...it isn't (bad gzip magic numbers);
looks like an initrd
Freeing initrd memory: 3814k freed
NET: Registered protocol family 16
EISA bus registered
PCI: PCI BIOS revision 2.10 entry at 0xfda95, last bus=1
PCI: Using configuration type 1
Linux Plug and Play Support v0.97 (c) Adam Belay
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00f3030
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0x28ea, dseg 0xf0000
PnPBIOS: Missing SMALL_TAG_ENDDEP tag
PnPBIOS: Missing SMALL_TAG_ENDDEP tag
PnPBIOS: Missing SMALL_TAG_ENDDEP tag
PnPBIOS: 17 nodes reported by PnP BIOS; 17 recorded by driver
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Transparent bridge - 0000:00:1e.0
PCI: Using IRQ router PIIX/ICH [8086/2410] at 0000:00:1f.0
pnp: 00:09: ioport range 0x4d0-0x4d1 has been reserved
pnp: 00:09: ioport range 0xcf8-0xcff could not be reserved
pnp: 00:0b: ioport range 0x800-0x87f has been reserved
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
NTFS driver 2.1.22 [Flags: R/O].
SGI XFS with ACLs, security attributes, realtime, large block numbers,
no debugenabled
SGI XFS Quota Management subsystem
Initializing Cryptographic API
vesafb: probe of vesafb0 failed with error -6
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 54 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
elevator: using anticipatory as default io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Probing IDE interface ide0...
hda: QUANTUM FIREBALLlct20 20, ATA DISK drive
Probing IDE interface ide1...
ide1: Wait for ready failed before probe !
hdd: CD-224E, ATAPI CD/DVD-ROM drive
Probing IDE interface ide2...
ide2: Wait for ready failed before probe !
Probing IDE interface ide3...
ide3: Wait for ready failed before probe !
Probing IDE interface ide4...
ide4: Wait for ready failed before probe !
Probing IDE interface ide5...
ide5: Wait for ready failed before probe !
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 39876480 sectors (20416 MB) w/418KiB Cache, CHS=39560/16/63
hda: cache flushes not supported
hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 >
hdd: ATAPI 24X CD-ROM drive, 128kB Cache
Uniform CD-ROM driver Revision: 3.20
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
EISA: Probing bus 0 at eisa0
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
NET: Registered protocol family 8
NET: Registered protocol family 20
RAMDISK: cramfs filesystem found at block 0
RAMDISK: Loading 3728KiB [1 disk] into ram disk... done.
VFS: Mounted root (cramfs filesystem) readonly.
Freeing unused kernel memory: 216k freed
NET: Registered protocol family 1
ICH: IDE controller at PCI slot 0000:00:1f.1
ICH: chipset revision 2
ICH: not 100% native mode: will probe irqs later
ICH: port 0x01f0 already claimed by ide0
ICH: port 0x0170 already claimed by ide1
ICH: neither IDE port enabled (BIOS)
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting. Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
Adding 1020088k swap on /dev/hda9. Priority:-1 extents:1
Adding 1020088k swap on /dev/hda8. Priority:-2 extents:1
EXT3 FS on hda6, internal journal
Real Time Clock Driver v1.12
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
ts: Compaq touchscreen protocol output
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
device-mapper: 4.3.0-ioctl (2004-09-30) initialised: dm-***@redhat.com
md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
Linux agpgart interface v0.100 (c) Dave Jones
USB Universal Host Controller Interface driver v2.2
PCI: Found IRQ 10 for device 0000:00:1f.2
uhci_hcd 0000:00:1f.2: Intel Corp. 82801AA USB
PCI: Setting latency timer of device 0000:00:1f.2 to 64
uhci_hcd 0000:00:1f.2: irq 10, io base 0xef80
uhci_hcd 0000:00:1f.2: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Linux video capture interface: v1.00
PCI: Found IRQ 9 for device 0000:01:0d.0
PCI: Sharing IRQ 9 with 0000:00:1f.3
agpgart: Detected an Intel i810 DC100 Chipset.
agpgart: Maximum main memory to use for agp memory: 93M
agpgart: detected 4MB dedicated video ram.
agpgart: AGP aperture is 64M @ 0xf8000000
hw_random hardware driver 1.0.0 loaded
cpci_hotplug: CompactPCI Hot Plug Core version: 0.2
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
forte: $Id: forte.c,v 1.63 2003/03/01 05:32:42 mkp Exp $
gameport: at pci0000:01:0d.1 speed 1242 kHz
parport_pc: Ignoring new-style parameters in presence of obsolete ones
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 5 [PCSPP,TRISTATE,EPP]
PCI: Found IRQ 11 for device 0000:01:0f.0
PCI: Sharing IRQ 11 with 0000:00:01.0
PCI parallel port detected: 1409:7268, I/O at 0xdff0(0xdfe0)
parport1: PC-style at 0xdff0 (0xdfe0) [PCSPP,TRISTATE]
input: PC Speaker
Capability LSM initialized
NET: Registered protocol family 10
Disabled Privacy Extensions on device c03f6480(lo)
IPv6 over IPv4 tunneling driver
Linux Kernel Card Services
options: [pci] [cardbus]
lp0: using parport0 (interrupt-driven).
lp1: using parport1 (polling).
PCI: Found IRQ 11 for device 0000:00:01.0
PCI: Sharing IRQ 11 with 0000:01:0f.0
[drm] Initialized i810 1.4.0 20030605 on minor 0: Intel Corp. 82810
DC-100 CGC [Chipset Graphics Controller]
[drm] Using POST v1.2 init.
Adeos: Pipelining started.
Adeos: Domain RTAI registered.
RTAI[hal]: 3.1 mounted over Adeos 2.6r9c5/x86.
RTAI[hal]: compiled with gcc version 2.95.4 20011002 (Debian prerelease).
RTAI[malloc]: kmalloced extent c4600000, size 131072.
RTAI[malloc]: loaded (global heap size=131072 bytes).
RTAI[sched_lxrt]: loaded.
RTAI[sched_lxrt]: timer=periodic (8254-PIT).
RTAI[sched_lxrt]: standard tick=1000 hz, CPU freq=1193180 hz.
RTAI[sched_lxrt]: timer setup=1676 ns, resched latency=2514 ns.
***** WARNING: GLOBAL HEAP NEITHER SHARABLE NOR USABLE FROM USER SPACE
(use thevmalloc option for RTAI malloc) *****
Registered /dev/emc with major 253
emcmot: SHMEM_KEY = 100
emcmot: PERIOD = 48000ns
emcmot: IO_BASE_ADDRESS = 378
emcmot: EMCMOT_TASK_PRIORITY = 2
emcmot: EMCMOT_TASK_STACK_SIZE = 8192
emcmot: sizeof(RT_TASK) = 992
emcmot: emcmotStruct allocated at 0xC8F61000 from rtai_kmalloc(100,688592)
Finished configuring emcmotStruct
ppmc_encoder found a Universal Stepper ver 1 module at IEEE-1284 address
0x 0
ppmc_rate V1.4 found a Universal Stepper ver 1 module at IEEE-1284
address 0x f
ppmc_dio entering ppmcDioInit
ppmc_dio found a Universal Stepper ver 1 module at IEEE-1284 address 0x f
emcmot: rtaiTickPeriod=57
emcmot: initializing emcmotTask
servoCycleTime=1000000ns
servoCycleTime=1193 ticks
emcmot: rtaiTickPeriod=57
emcmot: making emcmotTask periodic at a rate of 1197 ticks or 1003202
nanoseconds
emcmot: init_module finished
emcmotController started.
emcmot: cleanup started.
emcmot: deleting emcmotTask.
emcmot: disabling amps
emcmot: quitting analog, digital and motor interfaces
ppmc_rate V1.4 found a Universal Stepper ver 1 module at IEEE-1284
address 0x f
emcmot: releasing rtai shared memory.
emcmot: debounce counts: 0 0 2504 0 0 0 0 0
emcmot: cleanup finished.
RTAI[malloc]: kfreed extent c4600000, size 131072.
RTAI[malloc]: unloaded.
RTAI[sched_lxrt]: unloaded.
Adeos: Domain RTAI unregistered.
RTAI[hal]: unmounted.
Adeos: Pipelining stopped.
localhost:~#

[Jon Elson]

Post by Tim & Heather Smith

Post by paul_c
Typing in dmesg at the command line prompt returns all the messages
sent out by the kernel modules. Often when a module fails to load,
looking at the dmesg output reveals the reason for the failure.

Another way to do this is with :

tail -n 30 /var/log/messages

Which will print out the last 30 lines of the kernel message file. If
you are not logged in
with root privledges, you will need to put sudo in front of the above
command. It will
ask for your regular password the first time you use the sudo command,
and then
remember it for 30 minutes or so. (There is a setting that can prevent
the sudo command
from working, but I think the BDI install sets it up so it will work.)

Post by Tim & Heather Smith
ppmc_encoder found a Universal Stepper ver 1 module at IEEE-1284
address 0x 0
ppmc_rate V1.4 found a Universal Stepper ver 1 module at IEEE-1284
address 0x f
ppmc_dio entering ppmcDioInit
ppmc_dio found a Universal Stepper ver 1 module at IEEE-1284 address 0x f
emcmot: rtaiTickPeriod=57
emcmot: initializing emcmotTask
servoCycleTime=1000000ns
servoCycleTime=1193 ticks
emcmot: rtaiTickPeriod=57
emcmot: making emcmotTask periodic at a rate of 1197 ticks or 1003202
nanoseconds
emcmot: init_module finished
emcmotController started.
emcmot: cleanup started.
emcmot: deleting emcmotTask.
emcmot: disabling amps
emcmot: quitting analog, digital and motor interfaces

The latest version of ppmc_rate (the driver for the step pulse output)
writes out the
values it got from the SETUP_TIME and HOLD_TIME parameters in the ini file.
V1.4 (that version is not in sync with the CVS version numbers) doesn't
read these parameters from the ini file, they are hard-coded in the
source file.
I don't understand why this obsolete file is part of the latest BDI, as
I committed
this update on Jun 4, 2005.

I tried to find this file under the EMC2 tree, but it doesn't seem to be
there. Perhaps
Paul Corner has a CVS "tag" to preserve a particular level of code, but
I couldn't
find it. (Paul ?)

Anyway, it would be very desirable to have the the CVS ver 1.10 of
ppmc_rate.c
under the main emc/src/emcmot path put into the BDI CD, as it has the
code to
get the SETUP_TIME and HOLD_TIME from the .ini file. I can't do it
because I
can't even find where the obsolete file is getting into the BDI, no less
test it
right now.

Jon

[Ray Henry]

Post by paul_c
Hi Tim

Post by Tim & Heather Smith
I've done a little more investigating with the problem I have running
the USC card with BDI 4.23.
I also ran EMC from a terminal window and noticed an error I have not
seen before.
"Can not find -sec EMCMOT -var PERIOD -num 1
PERIOD not found"

Ignore warnings about PERIOD - This parameter is only used by freqmod..
One thing I would be interested in is the output of dmesg after setting
SETUP_TIME = 0 in AXIS_1 section..
Regards, Paul.

Hi guys

I'm not certain but what Pico grabs some of these ini variables and uses
them in ways that freqmod does not. I don't know if period is one of them.

I've seen a confusing problem during testing of 4.25 here. When I run
chips.ngc with just the backplotter, it will make it through the rapids
at the start but stops when it get's the feed move. The list of interp
conditions shows a proper feedrate but it never moves. When I abort the
program, the debug message simply shows a very long time for the move it
stalls on.

Ray

[paul_c]

I've seen a confusing problem during testing of 4.25 here.  When I run
chips.ngc with just the backplotter, it will make it through the rapids
at the start but stops when it get's the feed move.  The list of interp
conditions shows a proper feedrate but it never moves.  When I abort the
program, the debug message simply shows a very long time for the move it
stalls on.

[paul_c]

I've seen a confusing problem during testing of 4.25 here.  When I run
chips.ngc with just the backplotter, it will make it through the rapids
at the start but stops when it get's the feed move.  The list of interp
conditions shows a proper feedrate but it never moves.  When I abort the
program, the debug message simply shows a very long time for the move it
stalls on.

Add these lines to /etc/apt/sources.list

deb http://security.debian.org/ sarge/updates main contrib non-free

deb http://mirrors.neuron.net/emc-bdi/apt/ sarge updates extras
# neuron.net is an alt. for:
deb http://81.100.211.99/BDI-4/ sarge updates extras

Then do:

apt-get update
apt-get install emc-modules-2.6.10 emc


There was a small glitch in the 4.25 release that resulted in an abort being
triggered without user space being notified.


Regards, Paul.

[Markwayne]

That would be excellent if networking was working. I have not had
networking since I tried 4.23 at least, I cant recall which version I
had it working on last. I did have it working with the previous Debian
install on that machine I kicked off to test the 4.25 version so the
hardware is good. The card is a 3Com Etherlink III and I see it listed
as detected in the BIOS during boot. KDE info shows no network device
listed. Huh?

Mark

Post by paul_c
Add these lines to /etc/apt/sources.list
deb http://security.debian.org/ sarge/updates main contrib non-free
deb http://mirrors.neuron.net/emc-bdi/apt/ sarge updates extras
deb http://81.100.211.99/BDI-4/ sarge updates extras
apt-get update
apt-get install emc-modules-2.6.10 emc
There was a small glitch in the 4.25 release that resulted in an abort being
triggered without user space being notified.
Regards, Paul.

[Ray Henry]

Post by paul_c

Post by Ray Henry
I've seen a confusing problem during testing of 4.25 here. When I run
chips.ngc with just the backplotter, it will make it through the rapids
at the start but stops when it get's the feed move. The list of interp
conditions shows a proper feedrate but it never moves. When I abort the
program, the debug message simply shows a very long time for the move it
stalls on.

Add these lines to /etc/apt/sources.list
deb http://security.debian.org/ sarge/updates main contrib non-free
deb http://mirrors.neuron.net/emc-bdi/apt/ sarge updates extras
deb http://81.100.211.99/BDI-4/ sarge updates extras
apt-get update
apt-get install emc-modules-2.6.10 emc
There was a small glitch in the 4.25 release that resulted in an abort being
triggered without user space being notified.
Regards, Paul.

Darn -- this is copy and paste.

sudo apt-get update
Hit http://webersys.com ./ Packages
Hit http://security.debian.org sarge/updates/main Packages
Hit http://security.debian.org sarge/updates/main Release
Hit http://security.debian.org sarge/updates/contrib Packages
Hit http://security.debian.org sarge/updates/contrib Release
Hit http://security.debian.org sarge/updates/non-free Packages
Hit http://security.debian.org sarge/updates/non-free Release
Err http://mirrors.neuron.net sarge/updates Packages
Could not resolve 'mirrors.neuron.net'
Ign http://webersys.com ./ Release
Err http://mirrors.neuron.net sarge/updates Release
Could not resolve 'mirrors.neuron.net'
Err http://mirrors.neuron.net sarge/extras Packages
Could not resolve 'mirrors.neuron.net'
Hit http://ftp.debian.org sarge/main Packages
Hit http://ftp.debian.org sarge/main Release
Err http://mirrors.neuron.net sarge/extras Release
Could not resolve 'mirrors.neuron.net'
Failed to fetch http://mirrors.neuron.net/emc-bdi/apt/dists/sarge/updates/binary-i386/Packages.gz Could not resolve 'mirrors.neuron.net'
Failed to fetch http://mirrors.neuron.net/emc-bdi/apt/dists/sarge/updates/binary-i386/Release Could not resolve 'mirrors.neuron.net'
Failed to fetch http://mirrors.neuron.net/emc-bdi/apt/dists/sarge/extras/binary-i386/Packages.gz Could not resolve 'mirrors.neuron.net'
Failed to fetch http://mirrors.neuron.net/emc-bdi/apt/dists/sarge/extras/binary-i386/Release Could not resolve 'mirrors.neuron.net'
Reading Package Lists... Done
W: Couldn't stat source package list http://mirrors.neuron.net sarge/updates Packages (/var/lib/apt/lists/mirrors.neuron.net_emc-bdi_apt_dists_sarge_updates_binary-i386_Packages) - stat (2 No such file or directory)
W: Couldn't stat source package list http://mirrors.neuron.net sarge/extras Packages (/var/lib/apt/lists/mirrors.neuron.net_emc-bdi_apt_dists_sarge_extras_binary-i386_Packages) - stat (2 No such file or directory)
W: You may want to run apt-get update to correct these problems
E: Some index files failed to download, they have been ignored, or old ones used instead.

[Stewart Allen]

I just noticed this: all occurences of 'neuron.net' should be replaced
with 'neuron.com'.

stewart

Post by Ray Henry

Post by paul_c

Post by Ray Henry
I've seen a confusing problem during testing of 4.25 here. When I run
chips.ngc with just the backplotter, it will make it through the rapids
at the start but stops when it get's the feed move. The list of interp
conditions shows a proper feedrate but it never moves. When I abort the
program, the debug message simply shows a very long time for the move it
stalls on.

Add these lines to /etc/apt/sources.list
deb http://security.debian.org/ sarge/updates main contrib non-free
deb http://mirrors.neuron.net/emc-bdi/apt/ sarge updates extras
deb http://81.100.211.99/BDI-4/ sarge updates extras
apt-get update
apt-get install emc-modules-2.6.10 emc
There was a small glitch in the 4.25 release that resulted in an
abort being triggered without user space being notified.
Regards, Paul.

Darn -- this is copy and paste.
sudo apt-get update
Hit http://webersys.com ./ Packages
Hit http://security.debian.org sarge/updates/main Packages
Hit http://security.debian.org sarge/updates/main Release
Hit http://security.debian.org sarge/updates/contrib Packages
Hit http://security.debian.org sarge/updates/contrib Release
Hit http://security.debian.org sarge/updates/non-free Packages
Hit http://security.debian.org sarge/updates/non-free Release
Err http://mirrors.neuron.net sarge/updates Packages
Could not resolve 'mirrors.neuron.net'
Ign http://webersys.com ./ Release
Err http://mirrors.neuron.net sarge/updates Release
Could not resolve 'mirrors.neuron.net'
Err http://mirrors.neuron.net sarge/extras Packages
Could not resolve 'mirrors.neuron.net'
Hit http://ftp.debian.org sarge/main Packages
Hit http://ftp.debian.org sarge/main Release
Err http://mirrors.neuron.net sarge/extras Release
Could not resolve 'mirrors.neuron.net'
Failed to fetch
http://mirrors.neuron.net/emc-bdi/apt/dists/sarge/updates/binary-i386/Packages.gz
Could not resolve 'mirrors.neuron.net'
Failed to fetch
http://mirrors.neuron.net/emc-bdi/apt/dists/sarge/updates/binary-i386/Release
Could not resolve 'mirrors.neuron.net'
Failed to fetch
http://mirrors.neuron.net/emc-bdi/apt/dists/sarge/extras/binary-i386/Packages.gz
Could not resolve 'mirrors.neuron.net'
Failed to fetch
http://mirrors.neuron.net/emc-bdi/apt/dists/sarge/extras/binary-i386/Release
Could not resolve 'mirrors.neuron.net'
Reading Package Lists... Done
W: Couldn't stat source package list http://mirrors.neuron.net
sarge/updates Packages
(/var/lib/apt/lists/mirrors.neuron.net_emc-bdi_apt_dists_sarge_updates_binary-i386_Packages)
- stat (2 No such file or directory)
W: Couldn't stat source package list http://mirrors.neuron.net
sarge/extras Packages
(/var/lib/apt/lists/mirrors.neuron.net_emc-bdi_apt_dists_sarge_extras_binary-i386_Packages)
- stat (2 No such file or directory)
W: You may want to run apt-get update to correct these problems
E: Some index files failed to download, they have been ignored, or old ones used instead.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Ray Henry]

Post by paul_c

Post by Ray Henry
I've seen a confusing problem during testing of 4.25 here. When I run
chips.ngc with just the backplotter, it will make it through the rapids
at the start but stops when it get's the feed move. The list of interp
conditions shows a proper feedrate but it never moves. When I abort the
program, the debug message simply shows a very long time for the move it
stalls on.

Add these lines to /etc/apt/sources.list
deb http://security.debian.org/ sarge/updates main contrib non-free
deb http://mirrors.neuron.net/emc-bdi/apt/ sarge updates extras
deb http://81.100.211.99/BDI-4/ sarge updates extras
apt-get update
apt-get install emc-modules-2.6.10 emc
There was a small glitch in the 4.25 release that resulted in an abort being
triggered without user space being notified.
Regards, Paul.

I wondered if this was an abort because it didn't show any stopping of
the motion timer. The new makes no difference in the ability to run
3dchips.ngc. Stalls out soon after switching to feedrate from rapid.

Ray

[Jon Elson]

Post by Ray Henry

Post by paul_c
Hi Tim

Post by Tim & Heather Smith
I've done a little more investigating with the problem I have running
the USC card with BDI 4.23.
I also ran EMC from a terminal window and noticed an error I have not
seen before.
"Can not find -sec EMCMOT -var PERIOD -num 1
PERIOD not found"

Ignore warnings about PERIOD - This parameter is only used by freqmod..
One thing I would be interested in is the output of dmesg after
setting SETUP_TIME = 0 in AXIS_1 section..
Regards, Paul.

Hi guys
I'm not certain but what Pico grabs some of these ini variables and
uses them in ways that freqmod does not. I don't know if period is
one of them.
I've seen a confusing problem during testing of 4.25 here. When I run
chips.ngc with just the backplotter, it will make it through the
rapids at the start but stops when it get's the feed move. The list
of interp conditions shows a proper feedrate but it never moves. When
I abort the program, the debug message simply shows a very long time
for the move it stalls on.

My code for the Universal Stepper Controller (comes from source file
.../emcmot/ppmc_rate.c)
uses the parameters SETUP_TIME and HOLD_TIME in the first [AXIS_0] section.
I also don't know what SETUP_TIME = 0 would do, but it doesn't sound right.
SETUP_TIME is the time, in microseconds, that a step pulse is delayed
after a direction
change. A direction change is also delayed by the same amount after a
step pulse.
HOLD_TIME is the length of a step pulse, in microseconds. The values in
the [AXIS_0]
section apply to ALL axes. The SETUP_TIME and HOLD_TIME parameters in the
[AXIS_1], etc. sections are ignored, as the hardware in the board has
one global
setting for setup, and one for hold.

My default settings, which give solid performance with Gecko drives are :
[AXIS_0]
SETUP_TIME = 10.0
HOLD_TIME = 4.0

Jon

Jon

[paul_c]

Hi Jon

 The values in the [AXIS_0]
section apply to ALL axes.  The SETUP_TIME and HOLD_TIME parameters in the
[AXIS_1], etc. sections are ignored, as the hardware in the board has
one global setting for setup, and one for hold.

If that was your intention, then perhaps I should draw your attention to the
following snippet from ppmc_rate.c

43-__inline long VoltToCounts(double volts)
44-{
45- long Count;
46- int i;
47-
48- if (inited) {
49: PWMCycle = RateClock/emcmotConfig->setup_time[1];
50- diagnostics("PWMCycle = %d\n",PWMCycle);
51- i = 65535 - PWMCycle;

Line 49 looks wrong if setup time from AXIS_0 is the variable you want..


Regards, Paul.

[paul_c]

Post by paul_c
If that was your intention, then perhaps I should draw your attention to
the following snippet from ppmc_rate.c

Correction - That should be ppmc_pwm.c not ppmc_rate.c..

[Jon Elson]

Post by paul_c

Post by paul_c
If that was your intention, then perhaps I should draw your attention to
the following snippet from ppmc_rate.c

Correction - That should be ppmc_pwm.c not ppmc_rate.c..

Right. I'm glad these files didn't get mixed up somehow.

But, the [AXIS_0] parameters are the ones used by the stepper
controller driver (ppmc_rate.c), at least in the version I am using.

Jon

[Jon Elson]

Post by Tim & Heather Smith
Hi Jon

The values in the [AXIS_0]
section apply to ALL axes. The SETUP_TIME and HOLD_TIME parameters in the
[AXIS_1], etc. sections are ignored, as the hardware in the board has
one global setting for setup, and one for hold.

If that was your intention, then perhaps I should draw your attention to the
following snippet from ppmc_rate.c
43-__inline long VoltToCounts(double volts)
44-{
45- long Count;
46- int i;
47-
48- if (inited) {
49: PWMCycle = RateClock/emcmotConfig->setup_time[1];
50- diagnostics("PWMCycle = %d\n",PWMCycle);
51- i = 65535 - PWMCycle;
Line 49 looks wrong if setup time from AXIS_0 is the variable you want..

OH MY! If what you quote above is true, I know why the latest BDI (4.23)
is not working with the Universal Stepper Controller! That code is for
the Universal
PWM controller, NOT stepper! It should be in the file ppmc_pwm.c, NOT
ppmc_rate.c

See the file ppmc_rate.c in the EMC(1) section to see what code I have
running,
now, on older EMC systems.

But, I think you just grabbed the wrong file when quoting above, if I'm
looking
in the right place in the CVS. I changed ppmc_rate.c on June 4, 2005
to use
the values from [AXIS_0], which makes the most sense. Having ppmc_pwm.c
use the parameter from the SECOND axis [AXIS_1] is obviously a mistake,
and I should fix that at some convenient point. But, if you put the same
SETUP_TIME=x in every [AXIS_x] section, it will work fine.

Jon

[Jon Elson]

Post by Tim & Heather Smith
I've tried the enables in both states, with no success.
I'm at a bit of a loss, as that seemed the obvious thing to try.

One other thing, you need to use :
TASK = bridgeporttask

for the right connections between the task controller and the
USC board's driver in EMC. I don't think this will prevent motion,
but it definitely causes other stuff to not work right (aux I/O,
spindle, etc.)

Jon

[markwayne]

The 4.25 install I finally got installed had the same error message. I cant say what it causes in actual out put since I am only using it for simulation with back plot.

Mark

-----Original Message-----
From: Tim & Heather Smith <***@bigpond.com>
Sent: Sep 9, 2005 10:48 PM
To: emc-***@lists.sourceforge.net
Subject: Re: [Emc-users] BID 4.23 with Pico systems card

Hi Paul/Jon,
I've done a little more investigating with the problem I have running
the USC card with BDI 4.23.

I connected my Oscilloscope to the Gecko 201's step and Direction pins.
The Direction signal is definitely getting to the drives, but the Step
signals are not. ( I confirmed I could actually measure these on the BDI
2.20b setup, and I was able to see the Steps OK).

I also ran EMC from a terminal window and noticed an error I have not
seen before.

"Can not find -sec EMCMOT -var PERIOD -num 1
PERIOD not found"

Could this be a pointer to what my problem is ?

See entire messages from the terminal window below.


Thanks again.

Tim



localhost:~# cd /usr/local/emc
localhost:/usr/local/emc# ./emc.run
inivar = plat/nonrealtime/bin/inivar
INIFILE = emc.ini
RS274NGC_PARAMFILE = emc.var
starting emc...
starting EMC MOTION PROGRAM -- univstepmod...
Can not find -sec EMCMOT -var PERIOD -num 1
PERIOD not found
IO_BASE_ADDRESS 0x378
modprobe univstepmod IO_BASE_ADDRESS=0x378 SHMEM_KEY=100
done
starting EMC IO PROGRAM -- ppmcbridgeportio...done
Version: 1.2
Machine: PPMC
iniFind is depreciated
pptDioInit in ppmcparport.c, emcmotIo struct at 0xB7CE1A48
starting EMC TASK PROGRAM -- bridgeporttask...done
Version: 1.2
Machine: PPMC
iniFind is depreciated
Issuing EMC_TRAJ_SET_TERM_COND -- (+222,+16, +0, +2,)
Issuing EMC_TRAJ_SET_ORIGIN -- (+224,+60,
+0,-1.225000,0.000000,0.000000,0.000000,0.000000,0.000000,)
running EMC DISPLAY PROGRAM -- tkemc...
emcStatus->motion.traj.mode = 1
Issuing EMC_TRAJ_SET_SCALE -- (+209,+20, +1,1.000000,)
Issuing EMC_TASK_SET_STATE -- (+505,+16, +2, +2,)
Issuing EMC_TASK_SET_STATE -- (+505,+16, +3, +4,)
iosh: no process killed
pptDioQuit in ppmcparport.c
emc.ini was not changed.
emc.var was not changed.
Removing kernel module rtai_shm and anything that depends on it.
Including univstepmod
Removing kernel module rtai_hal and anything that depends on it.
Including rtai_lxrt
Removing kernel module adeos
localhost:/usr/local/emc#



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

[markwayne]

Yep me to me to. I thought I had another computer related problem (you wouldnt believe the PITA I have had) . What relief. I knew something was up when the execution stopped and when I exited the GUI there was not the usual shutdown messages in the console window. I saw another program do the same thing, it escapes me at the moment which it was but I will go see if I can reproduce it.

Mark

-----Original Message-----
From: Ray Henry <***@up.net>
Sent: Sep 10, 2005 9:42 AM
To: emc-***@lists.sourceforge.net
Subject: Re: [Emc-users] BID 4.23 with Pico systems card
I've seen a confusing problem during testing of 4.25 here. When I run
chips.ngc with just the backplotter, it will make it through the rapids
at the start but stops when it get's the feed move. The list of interp
conditions shows a proper feedrate but it never moves. When I abort the
program, the debug message simply shows a very long time for the move it
stalls on.

Ray




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf