Advanced Search

Like I said your hal and ini files are not readable. Please repost them.
What drivers are being used ?

Here is an example of what I am experiencing   . Each run is a different pocket run with the steppers at different microstepping values. Each time the bit goes down to start pocketing a new layer, the edge of the X axis of each is off from where it was from the layer above. What's weird is that each layer is lined up with itself in the X axis.

I'm not getting latency problems. I did input random high values (I think 20000 ns for each field) for the driver setup page because there is literally no information online about that (yes, I did contact the manufacturer - Troy).

I'm about ready to throw in the towel and buy new stepper drivers, but the things is, the drivers worked just fine not one week ago with the old controller.

I still have to figure out exactly how to get the GRBL controller to work with it but that's a different matter altogether.
I may be at the point where I have to switch to the Marlin firmware.  but we'll see.

  So it's been a few weeks since an update  and I figured I would post a few pics of my recent progress.
Did someone say 5th axis? Because that's what this is
 

 

And with a piece of foam mounted on it
 

The stepper has LESS torque, and we are using only about 1% of that anyway. It will still change tool to the next pocket in about half a second....

So no issues with torque. The issue is inertia ratio. Ideally I would have a 4:1 reduction and then I could whip the thing around 180 in 100 milliseconds... but we don't have that option right now. So as a result we have a quite high inertia ration, but since we also have a very simplistic motion path it should manage at slow acceleration.

I want also direct drive for now to test the absolute encoders on the servo with no other systems to cause me issues (like belts or gears and bearing assemblies)

Using a stepper would defeat much of the point of this.

I think you have two types of jogging mixed up.

gmoccapy can jog with a screen button/arrow like most GUis

This is quite different than using an external encoder
to jog.

I have step and direction ports available. But i need to test ethercat, so i thought it would be nice if i can mix and match for testing

1-2 secs accel sounds pretty terrible. This is where the low down torque of a stepper shines. I can get a plasma cutter to 10 m/min in 170 milliseconds with steppers.

This is not a CNC application but more of an industrial design problem. The work energy method is applicable
www.machinedesign.com/motors-drives/arti...rs-for-linear-motion
Here they use a 33% motion profile. For CNC, we settled on 1% profile
This video of mine explains further.
www.loom.com/share/64ef8fb135ad47bcaf006...33-b18f-4d63f2718a1b

Hi,

After advise from this forum I built my machines estop functions around a safety relay from Abb Sentry USR22. So i have dedicated hardware just for handling the latching, i have redundant safety contactors to take power to all moving parts and so on. Everything works all by itself and doesn't need LCNC to function. I can run the estop functions with LCNC completely turned off, just as i think it should work.

But I choose the USR22 since it have 2 groups of relays with a timed delay between them. In case of a estop, i'd like to first tell LCNC via the first relay that "shit has hit the fan, stop everything!" This happens via a simple IO-pin. Then after 400ms or so the safety relay will kill the power to servo-drives nomatter what via the 2nd relay...regardless of what LCNC do/did. The idea was that i would give the software a small window to command the servo-drives to do a estop via software(or do a "quickstop", whatever i can make work) and also the possibility to stop anything else that might need stopping, but isn't "deadly"(e.g. floodcoolant pump, liquid cooling system etc)...

But i'm unsure how to wire this in HAL for it to work properly inside LCNC. It seems like all examples are assuming that i just have the estop-button connected directly to a IO pin and then need LCNC to do the heavylifting in software. But this is not the case here. I want LCNC to do a "software estop" as fast as possible and likely also turn off other "non-critical stuff". I would also want LCNC to accept that the estop-condition is resolved whenever the IO-pin changes back again(no extra latching in software, i got all that in hardware). So the estop-latch examples doesn't quite fit as far as i can tell.

The signal from my safety relay is either high or low depending on the state of the estop. I tried to wire this to iocontrol.0.emc-enable-in, but this isn't quite right and i was curious if others have found a good way of doing this "properly"? Or has ideas how to do this?

/Thomas

rodw wrote:

gmoccappy has its own methods. See Chapter 5 in its docs
linuxcnc.org/docs/stable/html/gui/gmoccapy.html

 

The only thing I understood from the manual, is that it probably has something to do with these pins : To connect encoders, the following pins are exported:

• gmoccapy.jog.jog-velocity.counts (s32 IN) - Jog velocity
• gmoccapy.jog.jog-velocity.count-enable (bit IN) - Must be True, to enable counts
  
  
  net    encoder-counts    <=   hm2_7i95.0.encoder.00.count
  net    encoder-counts    =>   gmoccapy.jog.jog-velocity.counts 
  
  Am I on the right direction? Or am I misunderstanding things? My thought process is that the statement above connects the stepper motor encoder count(which is connected to the mesa board), to the gmoccapy jog counts. Therefore when you press the jog button -> count increases/decreases -> stepper motor moves

I hope I have not confused things with my very hardware/hal oriented
view. As Aciera mentioned GUIs typically use the python API for interfacing
with LinuxCNC rather than hal. So you will not see any jog related hal pins
used in the hal file

Note that if you want a MPG using an external hardware encoder 
its better to use hal rather than the python API as its real time
and not dependent on the user interface response time.  This is also true
of physical buttons.

Linuxcnc uses the NML messaging system for interprocess communications
The Linuxcnc python library uses NML
Gmoccappy uses the python library so no pins required 

ihavenofish wrote:

k, running my tool mag properties through yaskawas calculator to figure out inertia. you do quickly get out of range, but the 40mm 50w will be fine as long as i take some time accelerating. 1-2 seconds to get up to speed.

This doesnt need to be high performance, just for function testing.
 

Understood.  Earlier post was just a mild warning, not a hard THOU SHALT NOT sort of thing.

And if you don't feel like fiddling with ethercat, maybe plug in a 7i85s to get another bucket of S&D outputs for the ATC motor?  Assuming you've got a spare port, of course.

sudo apt install linuxcnc-uspace-dev is probably required
if working from source follow my video 
If you can connect apt to  Debian 13 Trixie you will have access to 2.9.3 in the Debian repositories

Life is so much easier if you stick to Debian

How is it possible that gmocappy jog buttons work after basic configuration? I Don't see any hal pin connections that make the jog buttons work?

P.s i know they somehow do work, but how and why do they work right out of the box after basic config? This is mostly to help my understanding of linuxcnc