Advanced Search

unknown wrote:

Aussie:

 but can chain an otto bin lid behind the bike

 

Dear Friend ... snow and drunk can be a good couple if after can go to sleep ..... my english I know is terrible .... after these I'm curious about your upper worlds ... seems like a figure to speech .... and honestly I know only "brass monkeys", no other unfortunately my flights is only for work, so is difficult to discover people culture. Here for me is a better place.

Ok you take a pause from work (chat gtp explain to me these is a typical australian slang) .... but where does these phrase came from? (I refer to ..... can chain an otto bin lid behind the bike ...) .

bye .... uknowwn member ....

For your actual machine I wouldn't bother with step/dir and go straight to another servo ethercat. Sell yours and with 150 difference you are already setup.

For your second machine take a look at FlexiHAL, you can directly slap a raspi5 in it. also they are designing a new board with Rj45 for step/dir and another guy is designing a board to swap A6 step/dir to Rj45. Join the printNC discord the board creator is there

My servos just need a boolean input, guess yours need the same

Just fresh installed PB and probing works like a charm. Check probe behavior in halshow?

Thanks for the reply. I updated about a month ago.

So the behaviour is. No matter what i change the probe will only search down 0.5mm

Then I get a message saying G38.2 move finished without making contact.

Thanks Chris

none yet, haven't had time with other more immediate machine issues im dealing with.

glad you got it resolved!

did you recently update? if so did you update all of the config files required for the latest version? if not as per the status page dics you may be missing some var file parameters that are not being stored persistently this could cause some issues.

when the probing stops what is the reason given in the status page?

First thing you'd need to do is convert your signed integer encoder counts and turn counts to floats using the CONV_S32_FLOAT hal component. Then you would need to multiply the turns by 65536 and that and the counts together to get the total counts, finally you would need to multiply the total counts by your encoder scale to get the distance (or if a rotary axis degrees.) You could do most of the summing and scaling in a single step using the SUM2 hal component since each of the SUM2 inputs have their own scale factor inpout.

But I'm not exactly sure how you might use that position information to set the home position for homing the axis in Linuxcnc. (But I think it could/can be done.) Also remember that data feedback from modbus isn't in real-time, and is subject to significant transmitting delays and resulting inaccuracy, So you will need to only use that feedback for position when stopped or only for "rough" positioning when moving.

If you build LinuxCNC now from Master you don't have to patch the kernel anymore from 6.12+.
To be clear, of course you still need a PREEMPT_RT built kernel.

Hi, any progress?
In the software there is not so much to change, but there is the MAX_ACCELERATION setting. It will restrict the acceleration if set lower in the ini file.
You can have a look and see what you have there. The last lines in StepGen3.h
 

I'm trying to follow Deje63's step by step to build the RT Kernel but I end up with an error:
"reversed (or previously applied patch detected) assume -R?" when trying to run command
"patch -p1 < ../patch-$RT_PATCH_VERSION.patch".
I'm not sure what it meant so I tried to patch anyway but end upp with make throwing "Error 2" at me,.on makefile:1921. Any idea what this might be and/or how to rectify it?

OR even better if anyone might be able to share an .img with LinuxCNC working with Rpi5 and built on RaspberryOS Lite.
I can't get the GPIO pins to work with the distro on the downloads page and it looks like in the man pages that a build on RpiOS is necessary for this to work...

Edit: attached Deje's txt-file for convenience. 

at least previous solution working not everytime .... these because Xinput v2 it seems .... seems these command helps QT_XCB_NO_XI2=0  .... so QT6 being obligate to use XInput2 ..... seems these solve the situation .... if you not find other mine post on these thread ... these issue is solved.

Precisely better insert the command in main.ccp ... qputenv("QT_XCB_NO_XI2", "0") .... previous of QApplication macro .... (solved)

regards

There is rumor of Big Tree Tech making one, but that is still just a rumor.

I spent some time digging into the rs274ngc code last night.  I don't think it's viable to modify the G10 L20 at that level to use the "actual" position of the joint.  I didn't see any references to "actual" position in the structures that contain setup/block info in that code.

I did learn along the way that the Z axis "touch off" offset value is stored in numbered parameter [5203 + (P * 20)] , in other words the Z axis workpiece offset for P1 (aka G54) is stored at #5223.  This parameter value can be viewed via an MDI debug command (debug, #5223) after a touch-off.  Writing the value directly with #5223 = 123.456 doesn't do anything useful.

So I'm probably best off trying to accomplish something via a small GUI modification, or maybe something with a clever G code remapping?