Advanced Search

Thank you....With the help of this Forum that is exactly the set-up I was gravitating to. The 5I20,7I33Ta,7I46 and three pieces of the 7I64.

I am sure over the next few months or so I will be a regular on here. I really just wanted my ticket stamped before I spent the money on the wrong hardware.

I do have another question on the computer. You mentioned the ATOM and it has on board Video. I read somewhere that on board Video could be a problem. I do have a few computers laying around but would like to start all new on this project.

Wit our cards, probably the simplest way would be to use a 5I23, for the controller, a 7I33TA for the analog servo/encoder interface, a 7I44 for High speed RS-422 interface and 2X 7I70s for Field inputs and 1X 7I71 for Field outputs
This combination of cards would give you 4 Axis of analog servo interface, (4 encoder inputs and 4 +-10V analog outputs). The 2 7I70s would give you 96 24V inputs and the 7I71 would give you 48 24V outputs

This leaves one FPGA connector and 5 high speed RS-422 channels free for expansion
This configuration will require EMC2.5 to support the 7I70 and 7I71.

The 7I70 and 7I71 connect via CAT6 cables ("Ethernet cables) and can be up to 100 feet from the controller. Sometimes this can help with wireing

A Mesa 5i20 + 7i33TA (servos and encoders) + 7i46 6 channel SPI breakout card + up to 6 7i64's connected to the 7i46 and you can have 144 inputs and 144 outputs and still have a 50 pin header open on the 5i20. I'm fairly sure that is a valid combo supported by EMC... just to be sure I asked on the IRC and I'm waiting on a reply. I think I saw that combo in a topic here...

duh there is a list of supported cards in the FAQ on this forum...

John

and interesting things maybe on
www.murga-linux.com/puppy/viewtopic.php?p=11578

I can't finf on wiki too...
But same thing is there

cuteminds.com/index.php/en/puppy

Thanks Jon your product does seem a bit more straight forward to me the more I research and learn. I do believe my problem is the input. It will need a 60 Inputs and 20 Outputs to keep this machine fairly close to operating the OEM way. This machine has 76 DC inputs and 33 Outputs before reto-fit.

All I can find is this

www.thecooltool.com/produktgruppe.php?la...itel=CoolCNC+-+Linux

but all the links now appear dead or removed.

Rick G wrote:

Is this where you started?

www.puppylinux.com/about.htm
wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emc_Puppy
wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CoolCnc.0.5

Yes it's this. But somwhere deep is live CD compilation. And I do from live CD. (not build from myself)

E_M_C_user wrote:

The problem is that when I am doing manual jogging of the axis using the keyboard, sometimes it moves in the wrong direction and then it corrects itself. Other times I would have to unpress the keyboard and press it again to get it in the right direction. However, EMC2 thinks it has been travelling in the right direction all the time. This problem does not happen all the time, but quite often. I'd say 60% of the time.

That does sound more like an electrical problem like a loose connection or a bad driver board.

John

Polar Coordinates

www.linuxcnc.org/docview/html/gcode_main.html#r1_1

John

Rick G wrote:

Is this where you started?
wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emc_Puppy
wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CoolCnc.0.5

Thanks Rick

Quite a comprehensive outline from Alex Joni and cncuser, albeit 2.4.x kernel and most of the links will be dead by now.

I had forgotten that Qemu existed! Not used it since the old king died!

My problem is going to be my hardware being too new, think I am going to have to find the lightest i386 / x86 distro (preferably debian based) that will still install and run in a basic video mode on my machines and then go from there.

regards

eslavko wrote:

As I already write.
So Rtai is not the problem. But the EMC2 bundled in that is just to old.
So the question is how to compile EMC from source on puppy.

If you have a working Puppy Linux emc install with rtai kernel, but want to upgrade EMC that should be a lot easier.

The place to start will be downloading an emc source package, put it in /usr/src/ and from the ../emc-versionxx/src directory run ./configure --enable-run-in-place and then each time it finds an un-met dependency, download that and run configure again.
There will probably be quite a lot of them, I don't know how much quite basic stuff is included in the distro.

Once a makefile is generated, make, make setuid, and then to run in place . ./scripts/emc-environment and emc.

If it works OK you can use it like that or can go back and make clean then ./configure --prefix=/usr, make, make install

Your problem is likely to be the library versions included in PL being too old for the EMC version you are trying to compile, which is why I was thinking towards getting the newest version of PL that will run on your hardware and starting from there.

In fact I have no allegiance towards PL at all and would probably rather have a debian based distro if possible, just for sheer familiarity and for ease of updating.

regards

Is it just the one axis that has a problem?
Is backlash compensation turned on?
Can you change the pins / wiring from one axis to the other temporally to see if the problem stays with one axis or moves to the other?


Rick G

Is this where you started?

www.puppylinux.com/about.htm
wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emc_Puppy
wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CoolCnc.0.5

E_M_C_user wrote:

My direction hold timings are the default ones, but Ive also played with them too to no avail. I assume too fast = small number, and Ive tried fast and slow. Im wondering, does it need to be optimized or a really long direction hold is fine, its just the milling is slower (this doesnt bother me as long as my CNC works first).

You will probably never see the difference between minimal and super-long dir setup, as an axis is always moving at zero speed when you change direction.

I just realized from the changelogs it is up to version 2.4.7. My version is 1:2.4.3.1. The version that comes from the live CD. Is there bugs with this that can cause the problem? In any case, the problem occurs even with sherline's own live CD and using their version of EMC.

As far as I know there have been no changes.
Can you halscope the axis position/velocity pins during jogging, and see if EMC2 is commanding the wrong move, or commanding the correct move, and getting the wrong move?