Advanced Search

Gusgus wrote:

Hi again and thanks for all the help up until now!

I wan't to give more context and explain myself better, we have been using this cnc router since 2023, originally setup with a raspberry pi 3b and octopus pro combo, it has worked wonders and is amazing the only real issue is that the raspberry pi 3b was slow. Recently we made the change to a raspberry pi 5, we took the original .ini and .hal files which we then update to be compatible with the new remora version, we kept the same config.txt file. We installed the linuxcnc-raspberrypi5 image and installed the remora components as instructed in the documentation.

The issues we've seen: when we first loaded linuxcnc and ran the .ini file by double clicking on it and choosing linuxcnc as the app to run the ini file we then saw the raspberry pi 5 using rp1 driver alert, we initially thought this was error but figured this was just an alert and so continued. We then started testing leaving e stop we could but just for a moment, no more than 3s, we could even get to enable but non of the drivers actually enable. We then tested if this was the E-stop's fault but we assumed it wasn't since if we disconnected the estop we could exit estop at all, wehn it was properly setup we could but can't enable the steppers fisically. This isn't a stepper issue or driver issue since they get enabled with the raspberry pi 3.

Thanks in advance and thank you for all of the help until now! Oh and sorry for any grammar or spelling mistakes, english isn't our first tounge.

Ok, so I pulled out my octopus board and RPi5 to see what could be the issue. I found my working config and noted:

#SERVO_PERIOD = 1000000
SERVO_PERIOD = 5000000

Making this change to your config, I got it up and running. With the faster servo period the board was throwing so many communication errors.

There is  </vbox> missing at the end of of the .xml file

Sorry to bother you again guys. With the help of some people I have the axes and the spindle going now.
My current issue is the homing of the axes. They do not move to search for the home- switches, but just home "in place" so just where they stand. Obviously the axes pretend to "be homed" then, because softlimits are active. Signal joint.1.homed swaps immediately to yellow
If I unhome all axes I can move them where I want by jogging them- otherwise the + way is limited as it should be to 5/10mm +.
The hm2_7i80.0.gpio.026.in reacts in HAL-show on pushing the home switch manually and also the signal  "z-home-sw" swaps from red to yellow together with hm2_7i80.0.gpio.026.in.
The signal "z-is-homed" stays red .... if this is of any importance.

It is just that the search for the HOME signal does not take place. When trying to home an axis the axis motor is activated, stops immediately (does not move the axis) and sets the DRO value to 0.0
Any help appreciated
Thank you
Sigi

Yeah, I commented those out to get LinuxCNC to start so I could look at the halui component in halshow, to see if maybe the pins were numbered differently than I expected or something. With those lines uncommented LinuxCNC won't start, since the mdi-command-NN pins don't exist.

Thanks for mentioning it though, I've certainly had forest-for-trees errors like that before where another pair of eyes spotted the problem immediately. 

Just in case you are not aware that in the # Syringe section in your postgui.hal everything regarding mdi-command is commented out.

I’m aware of how it’s _supposed_ to work, my question is what I’m doing wrong in my configs that make halui not expose mdi-command-00 etc pins despite the presence of MDI_COMMAND entries in the [HALUI] INI section, and HALUI=halui in the [HAL] section?

Hello all,

I'm a basic user of LCNC - I know it reasonably well, but don't use a tool changer, only have a basic through tool Z probe which gets occasional use - you get the idea: my set-up is pretty rudimentary but I get good results and productive use out of the software.

When I need to find the centre of a circular feature I've been touching a dowel off at three points around a circumference (fag paper or multimeter method) and feeding three sets of X,Y coordinates into a spreadsheet which then works out the centre for me, like so:





Here's the sheet in OpenOffice format.

It works, but I was wondering if there was a way to incorporate a simple centre finder tab into the interface, something that would look a little like this:

 

The first three buttons to touch off the three positions on the circumference and the 'FIND CENTRE' button to perform four ops:

Calculate the X,Y centre coordinates
Lift the Z axis to its G53 0
Move to the calculated X,Y centre
Set G54 (or current WCS) X,Y to 0,0

So I guess there would need to be six variables that get written using date from 'current position' numbered parameters #5420 & #5421

POSA_X
POSA_Y
POSB_X
POSB_Y
POSC_X
POSC_Y

And then the two calculated variables that are used in a subroutine to lift and move the spindle to the centre and zero out X,Y at the new position

CNTR_X
CNTR_Y

I get that this is still clunkier than using a probe, but I honestly have little need for one!  If I have to keep punching the numbers into the spreadsheet then that's fine, but to have this in a tab would be cool.  Am I thinking about this in the right way?

How would you tackle it?

Many thanks.

Wal.

If anyone stumbles on this looking for a solution I was able to work it out in hal using wcomp and some and, or, not components. Basically I used the wcomp to check the startup position from the last_position.txt file, then using a bit of funny logic I made it so after the joints hits the home switch in the positive direction, the wcomp keeps the home switch closed for the remainder of the positive direction travel, then in the negative direction I used the min wcomp output to disable the home switch input for the remainder of the negative travel. So the home switch only properly works in a narrow joint position range. With this setup the normal homing routine does exactly what I need. When the joint is in the positive direction it backs off until it's in the proper range and in the negative direction it ignores the physical switch until it's in the proper range. There's some silly logic with some and/or/not comps which I'm sure could be made more elegant, but it does work.

An MDI command can be executed by using halui.mdi-command-00
Here is an example showing how it 's done:

linuxcnc.org/docs/html/gui/halui.html
 

I found a few lpf files.. like the one litex generates, and the one here:
github.com/ZeroMips/Colorlight-5A-75B-gp.../master/gpiotest.lpf

However, when I program the bitstream, it doesn't seem to be doing anything. Even a simple led blink. 

Opening the lpf in Lattice Diamond, I notice that these lpf files show errors in the spreadsheet view.. so I think Lattice is ignoring the pin assignments all together?

 

W8 must be down

To see the 5ABOB specific pinout:

mesaflash --device 7i96 --addr 10.10.10.10 --dbname3 5abob --readhmid

For posterity, I have managed to solve this by writing a little HAL component  that works by switching between OR and AND depending on whether the machine is over the tool setter with the touch probe loaded in the spindle. Feels a bit like redneck engineering, but hey, if it works it works.

There's also a simplistic probe crash protection, I was actually surprised when I wasn't able to find this feature elsewhere.

thank you for the help, I did a fresh install using the latest image and got mesaflash to work, the proper firmware is now on the board.

I have a few more questions before I fry my card

when connecting the bob o the 7i96 in what position should W8 be?

what is the correct adress for the P1/PWM pin on the bob?

Thanks!!! Not sure how I could have missed that one. I posted something right after it, but my focus back then was on Trixie, not on EtherCAT. I feel so stupid now Anyway, I'm sure I will get it fixed with that info. Again, thanks!

Hoping someone can point out the probably obvious error in my configs that is causing halui.mdi-command-NN pins not to be created.  The halui component loads and the rest of halui's normal pins show up in the HAL Configuration tree; in the [HAL] section I have the HALUI = halui line; I've made sure the [HALUI] section in the INI file exists and that there are MDI_COMMAND entries under that heading, but still no joy.  Can someone see what I've missed? 



Thanks.