Advanced Search

I was using remora on BTT Octopus pro board. Few days back I had to remove the board for some reason. Now it's not working. Nothing has changed. I tried erasing and reflashing remora by stm32 programmer. Tried changing spi cable from board to rpi4. I can see remora firmware is working on board. I added blink module to verify remora, it's working. I can see via UART console that remora ha loaded correctly and comes to idle state.
But on LinuxCNC side machine don't comes out of estop. No configuration changed. Tried new trixie image but can't compile remora due to incomplete pointer error. Don't know what's going wrong? 

Hi all,
thanks to Hakan, I’m now able to control all the motors without any issues.
However, could someone help me with this error shown by the code dmesg command:  dmesg.txt
Could this error cause problems during machine operation?

Many thanks, Lorenzo

Thanks for the test image.It solved the issue on CM5-7i95 detected and linuxcnc running with hm2_eth and working I/O.Much appreciated.

You could order another thumb drive and request one with the latest PathPilot already on it. Dunno if they'd do it. The last one I ordered had 2.8.3 installed, but that was a while ago.

After creating the new profile, I was comparing the Y configuration in the .ini to the Y2 configuration and both to the original single Y axis configuration. I noticed the the HOME_SEQUENCE for Y and Y2 is set to -3 in the dual Y axis configuration rather that 3 like the original single Y axis configuration.

I seem to remember reading in the documentation that when the HOME_SEQUENCE is set to the same value for two axes they both home together. Is -3 correct for a dual Y axes configuration?

Kind Regards,

Hi Aciera,

Thanks for the reply.

So if the intersection of the A and C axes for Dx=0 is below the bed (as in my case which I have shown in above screenshots.) the the rot-point is also at that point as denoted in screenshot with point A.

Is my procedure correct or is it point B from where we should take rot-point?


Regards
Abhishek

Thank you for your previous reply and guidance regarding the RS-422 interface
on the 7i76 and the suggestion to use an external RS-485 transceiver.
That explanation was very helpful.

I am currently using the 7i92_7i76x2d_2pwm bitfile, and I have reviewed the
IDROM configuration using mesaflash.

From the IDROM, StepGen 5, 6, and 7 are mapped to P1 DB25 pins
1/14, 2/15, and 3/16. These step generators are unused in my system.

I would like to ask whether it would be possible to replace StepGen 5–7
with two additional QCount modules (Quad-A, Quad-B, and Quad-IDX),
using those same I/O pins.

If this is feasible and acceptable from a resource standpoint,
would you be willing to provide a custom bitfile with this change?

Thank you again for your time and for your continued support.

So I find out 3 different Linuxcnc o.s later that I should just settle with 2.9.4 because the cards were new versions “2025” mesa boards…. 2weeks of wrestling with a combination of ip address, firmware,software, etc I’m at a complete stalemate. Really wish I would have just went the g540 route, I was able to flash the firmware. Same firmware I downloaded off of mesas site 7i92tm software. Onto a usb drive loaded onto desktop move the file over to desktop it’s already unzipped so I go in and tell the terminal which combo I have “ 7i92tm_7i76u. I believe the file ends with x1pd.bin? If I’m not mistaken. Anyways, Wrestled with the flash “spelling “ supposedly for about 3 days. Finally got it flashed. Now when I go in pncconf in the pin config setup/card discovery picks up a combo of “7i92 internal data”no tm” next box down shows the combo 7i92 with 7i76. Kool! But in the pinout only the tb4 tb5 tb6 terminals show. 7i76u “2025” step dir goes on tb2 and tb3, only it’s like they don’t exist and now im thinking about just being a chef 

I assume you are talking about the 5axis trt kinematics. If so see section 5.2 for a description of offsets Dx and Dz:
linuxcnc.org/docs/master/html/motion/5-axis-kinematics.html
Rot-point is the intersection of the A and C axes for Dx=0.

Hi everybody,

I have a small doubt which I hope you all can clarify.

For my z-rot-point calibration,
In my case I think the z-rot point is the distance between z-machine-zero position to the primary rotary axis pivot point (in my case A-axis pivot point) is the z-rot-point value i.e.as shown in screenshot 1: The vector from the origin of the machine coordinate system to point A on the first rotation axis of the table is set as the rotary table position in the machine coordinate system.

Similarly for z-offset in screenshot 2: When the rotation axes for controlling the table are all at 0 degrees, the vector from point A to point B on the second rotation axis of the table is set as the intersection offset vector in the machine coordinate system.

if tell me whether what I have done is correct or not.
Because I went through many threads in the forum but in most cases the rotary point of A-axis is at higher level(in Z-axis term) then the bed(C-axis rotary point) and in my case it is opposite.



 

Yes it does, if I jog the axis it will change. It doesnt seem to be realted as to how far I jog, the axis just has to move, even 0.1mm

The scurve is present now in linuxcnc master, download from GitHub and build, or use the latest .deb files

With many thanks to Grandixximo and 杨阳 we now have an experimental
S-curve / finite-jerk trajectory planner for testing.

For those that build from source just look for the new v2.10.0-pre1 tag.

Others can download debs from github for the next 90 days:
x86 / bookworm  github.com/LinuxCNC/linuxcnc/actions/run...artifacts/5056097663
x86 / trixie github.com/LinuxCNC/linuxcnc/actions/run...artifacts/5056161668
ARM64 / bookworm github.com/LinuxCNC/linuxcnc/actions/run...artifacts/5056139840
ARM64 / trixie github.com/LinuxCNC/linuxcnc/actions/run...artifacts/5056124080

Make no mistake, this is experimental, there are no guarantees that
these won't break your machines. The first user already hit the hard
stops when homing (too-low max jerk setting)
With the jerk setting it is probably best to start high and reduce, as
infinite jerk is closer to current behavior.

If you run these you are volunteering to be a guinea-pig.
magazine.punch.co.uk/image/I0000NOWOOdkXT_k

Life has got more complicated. With proper kernel tuning, latency can be better with Debian 13. I am in the process of publishing a second video about this on YouTube. Please refer to my channel. www.youtube.com/@MrRodW
The yet to be published video should be watched before the current one.

If you zero again, does the small values stay the same?