Advanced Search

I'm currently working on the Probe_basic version. In the Handrad.hal and probe_basic_postgui.hal files, there are two lines that are causing problems. I’ll just copy the relevant parts here:

handrad.hal
net pdnt.program.is-idle whb.halui.program.is-idle halui.program.is-idle
net pdnt.program.is-paused whb.halui.program.is-paused halui.program.is-paused

and

postgui
#net prog-running not.0.in <= halui.program.is-idle
#net prog-paused halui.program.is-paused => time.0.pause
net cycle-timer time.0.start <= not.0.out
net cycle-seconds qtpyvcp.timerseconds.in <= time.0.seconds
net cycle-minutes qtpyvcp.timerminutes.in <= time.0.minutes
net cycle-hours qtpyvcp.timerhours.in <= time.0.hours
# *** Time items required for Probe Basic to run ***

As far as I understand, program.is-idle starts and “resets” a timer, and program.is-paused pauses the timer. 

I _will_ try to do the feedbback test again as I think I only connected the stepgen fb to joint fb, not pid fb aswell.

The drive is at 10000 PPR and around 1.45:1 spindle:motor overdrive, from my calculations 6k rpm spindle speed is around the limit. there is a 2500 step/10k line encoder on the spindle itself I use for feedback.

I am looking through the HAL again and wondering maybe I DO have the scaling wrong? Though the positions and speeds report correct, maybe the scales are backwards, the end math turns out correct, but calculations midway are off? I'm trying to think of anything now, really.

• -ENCODER_SCALE is 10000
• -Spindle SCALE is 114.83 (10000/1.45/60) (not sure why it needs to be divided by 60 though? I assume because RPS instead of RPM, but I thought this value should not be bound by time, only steps/rev? I'm not sure...
• -JOINT_2 (C axis in my case) SCALE is 19.07 (10000/1.45/360). I turned on the scale switching in M102/103, not sure how you get it to work without that?

What makes me think that I have something off is the scaling by 360 of the enc-pos signal in the HAL. As in I have 10000 lines per rev, so multiplying it by 360 instead of dividing makes no sense to me the way I have it now. 

Yeah that’s the one

Hi everyone,I’m very new to LinuxCNC and Mesa boards, so I might be missing something basic here, but I’ve been stuck on this for a while and could really use some guidance.I’m working with a Mesa 7I76EU and setting up stepgens in LinuxCNC. When I use TB3 (channel 4), everything works perfectly. The motor moves in both directions, the direction signal changes correctly, and I can clearly see step pulses on the oscilloscope.The issue is with TB2 (channels 0–3). No matter which channel I use, I don’t get proper behavior. At first, measuring to ground made it seem like there was no voltage at all, which confused me. Then I realized these are differential outputs and started measuring across the pairs instead.On TB2, I can see step pulses across STEP+ and STEP− (about 5V differential), so the channel is definitely active. But the DIR signal (DIR+ to DIR−) stays constant at about 5V and does not change when I reverse direction. Also, the step pulses only show up when jogging in one direction, not both.In HALShow, the stepgen for that channel looks active. Enable is true, velocity command changes sign when I jog forward and backward, and position feedback and counts are updating. So from LinuxCNC’s side, it looks like the commands are being generated correctlyWhat’s confusing me is that TB3 works perfectly under the same setup, but TB2 behaves like this. At this point I’m not sure if this is something I’m misunderstanding about configuration or differential signals, or if it could be a partial hardware issue affecting only TB2.Has anyone run into something like this before? Any suggestions on what I should check next would really help.Thanks a lot

There was a problem with the limits and the estop on the input pins. I got that all figured out and now the machine is working and homing. I just now have to get it all tuned up. Thanks again for all your help.

I think the best way is to have linuxcnc at the centre.
For custom control you write a hal component
that takes signals in and gives signals out 
with your control algorithm.

received support, it is working

I really don't know the answers here, but maybe some things you can try while you wait for someone smart to chime in...

Disconnect the encoder feedback and just use the stepgen position  - i.e. run it open loop.  Still choppy?

EDIT - nevermind, you already did that

Check the step-to-distance values.  Do you have really coarse steps per degree/rotation or something?  I'd start by:

• Figuring out the maximum input frequency of your drive
• Do some math
• Set the drive's internal steps-per-rotation to as high as possible without exceeding the max input freq at your maximum spindle speed
• Adjust INI & HAL files so the spindle and axis steps-per-whatever match your new drive parameter values
  
  I don't know if either of these will help, but they're free to test.

I indeed have all the axis stepgens in control_type=1, really all I changed from yours in spindle config are the step and encoder scaling pretty much.

That was sort of a weird for me that other axis work fine, but C axis has this choppy behaviour. Obviously it's the only one with actual feeedback but I tried looping back stepgen pos-fb instead of encoder feedbackk in the hal, which should in my head mirror the setup of x and z axis, however the choppiness still remained. Unless I'm missing something silly again

Hi All,

have an early 7c81 with I bought couple years ago to use with the PI4, but that system was to slow for my setup.

Now I like to replace my rater large PC with a PI5 setup, but I found out that I have to flash it with a PI4 to make it work.
Can I flash the 7C81 with a PI3 instated?
I tried but it doesn't seem to connect, the wiring is correct and SPI is enabled.

do I have to use a certain version of Mesaflash, I have 3.5.11 from the LinuxCNC image.

 

Keep in mind that we're reaching the limits of my competency...

I think the typical/standard configuration is to put the LCNC stepgen in velocity mode (stepgen.N.control-type = 1), and let LCNC's PID manage getting to the target position.

I seem to recall reading a forum post a while back describing where some developers discovered (years ago) that a velocity-mode stepgen w/PID wound up being more accurate - or otherwise 'better' - than a position-mode stepgen.

So instead of using stepgen.N.position-cmd as the PID output, stepgen.N.velocity-cmd is used.  Or something like that.

How are your other axes controlled?  Velocity-mode or position-mode stepgens?

Thank you for the clarification. What can I find the EtherCAT setup instruction? I only see an example for stepper drive. The reason I want to use API, because my system is not only doing CNC motion, but it may include other sequence. I am not familiar with LinuxCNC enough.

hilinda1 wrote:

I prefer to use API for my application. Please advise. Thank you guys.  


 

That is all good and dandy, but why?
LinuxCNC has several trajectory planners that you can switch between, so why add another layer between them?
Check the docs and GitHub, you can probably add another API there somewhere, so try the Run In Place version as you can change stuff and test quickly.

Todd wrote:

I believe you can use a switch, but the switch and the PCs ethernet port need to be dedicated only to this use. If you want to also have an ethernet network/internet connection you will need a second nic on the pc for that.

 

I have not tried that recently, but it has worked for me in the past. I had two Mesa cards connected to a switch, each with its own address.

When I tried connecting other devices to that switch, (modbus tcp, etc), that did not work. Those needed an additional NIC.

Some switches do not behave. I tried using a router instead of a switch one time, that did not work either.

LinuxCNC is a fully-fledged CNC controller.EtherCAT Cia402 is supported.I don’t think you can extract any parts for your purpose.It wouldn’t make any sense anyway.