Advanced Search

Hannes wrote:

@rodw: Jogging in manual mode is fine. My machine can not jog in teleop mode due to I have two Y axis servo motors. The only thing the WHB component does after my PR is:
- Change to teleop mode if not homed (which fails on my machine but on others, it will do that) -> You can jog before homing any special action
- Change to manual mode if homed AND program is idle -> You can jog after homing without any special action

In this case its far better to disable motion before homing with a simple change to the ini file. I still have no idea why people want to move or jog before homing. None of my machines allow this! And yes, one was a XYYZ gantry plasma table that jogged with a pendant perfectly!

andypugh wrote:

G71 and friends exist mainly as an alternative to CAM, to make hand-coding easier.
I don't know of any CAM system that generates G71 (which isn't to say that there aren't any). But I don't think much would be gained from doing so.
 
 

I am not familiar with any other CAM software for turning, but Fusion360 / HSMworks / Inventor CAM can do this.
 

The standard LinuxCNC turning postprocessor from the HSM library does not work without corrections (it uses Fanuc-style UVW for incremental offsets, which LinuxCNC does not understand). I don't know who added this post or why these corrections haven't been made in almost ten years.

G7X canned cycles are also not defined in this postprocessor, but you can add them by following the standard Fanuc turning postprocessor example. This will probably require verification and correction to match the LinuxCNC code-style. The cycles are defined in the following functions:
function onCyclePath()
function onCyclePathEnd()
 

From the start I was having some serial communication errors now and then, that were caused by something regarding to Y-axis movement. Sometimes the issue happened once in couple months, but two weeks ago it happened almost every time I was using the machine. I did some research and tested and investigated pretty much everything, and I noticed that with only the cfq=f, using only the fanuc grayscale for bldc commutation, there were one spot four times in revolution that the motor did not have that much torque, and probably caused rotor phase current to rise quickly causing EMI issues.

But after that was discovered, I decided that i want to use the qi mode, so possible encoder replacement could be easier and cheaper in future if needed to be done. I have been fiddling with the init settings. I want the rotor alignment sequence to work in a way that when I open linuxcnc for the first time, press machine on button in GUI (F2), the rotor will do the rotor alignment sequence that ends when it finds the index mark. But, if the power-off or E-stop is pressed and after that turned back on, the alignment sequence would not be done again, because the encoder count is not interrupted and the rotor alignment should correspond to that still. I haven't had any luck with getting this to work like that, so now id like some advice or if somebody has used same kind of configuration for the same thing I would be grateful.


Here is the hal confiq from the Y-axis and ini file. So this works OK for the Y-axis now, exept id like to make the rotor homing only once:

   

Great work so far.
I am just not sure i fully understand it all yet.
Does that mean that with the installed PR from end of 2025, SyncToRefClock=True fixes it all? Or is the currently open PR still needed?

Thanks!

Tested the latest changes, and everything works as expected. Thank you!

Yeah. I also grepped for usleep at one point, but didn't really bother trying to figure out if it will cause issues elsewhere. If you go back to some of the first posts, you see I also considered writing a completely new component. Part of the reason for that was to have a state model and avoid these blocking sleep calls. The other part was that I think that the level of abstractions used is bordering on ridiculous for the application. The xhc-hb04.cc component has one order of magnitude less lines of code and does more or less the same thing. But now that you are fixing things, and with my own firmware, I personally don't see a need for a completely new component at this time.

Thanks for testing!

There might also have been a bug in libusb. This kind of error handling is always difficult to test when you don't have errors.

I did not go that deep into USB. But your explanation sounds reasonable. I changed it to interrupt. It did not make a difference for me but rather correct than wrong but still working, I pushed a new commit. Feel free to test if you did not test that anyway already.

Note: There are also other usleep() in hal.cc. So they might also give issues. However, fixing that is a lot of effort. I thing it's easier to write it new from scratch using parts of the existing code. But if it works now, that's fine anyway...

I tested the errorhandling branch by modifying the requestManaulMode back to the original. Then I can get the dongle to disconnect reliably. While I maybe did not do exhaustive testing, the dongle reconnected successfully every time I generated a disconnect. So at least based on this your code is working as expected.

Also with the original code, the pendant would reconnect for me if I simply removed the assert statement. I know that no "restart" is triggered from that alone. But because the USB device has been disconnected, the libusb_control_transfer will fail just a few moment later, and that will trigger the restart. For Hakan it didn't reconnect, but that was because it segfaulted in libusb. Anyway, now the assert statement is gone and there is some proper handling of the libusb_submit_transfer errors.

While you are there in the setupAsyncTransfer function, the libusb_fill_bulk_transfer() should really be a libusb_fill_interrupt_transfer(). If you do a lsusb -vvv, you see that endpoint 1 IN is really an interrupt endpoint:The bInterval means it should be polled every 2 ms (for a full speed device, as this is). I don't think that is guaranteed by a bulk transfer. And the interrupt transfers should also be given higher priority on the bus than bulk. I'm not saying that using bulk transfer causes issues. But because we have also had disconnect that are in my opinion not related to mode switching, it's at least possible that using interrupt transfers instead of bulk could improve the situation. And it's the right transfer type to use...

clear as mud lol. is there a more supported module thats plug and play

Errors with limits have nothing to do with what Linux or version of LinuxCNC you are using, the are a setup issue, namely just invert them in hal or in the wizard.

Probably about 2 weeks now before Mesa has new stock.

Anyone got info on when 7i96s will be in stock again? Been out of stock for a while at mesanet.com. 

Cheers. 

Hi, I am a newbie and I am having the same issue. I tried the bundled package with debian 12 Linuxcnc 2.9.4 iso and installed it. After starting the pncconfig and trying to run the board I got errors with the limit/estop/probe input on TP6. I set those to not used and I could get pulses on the board for movement. If I try to reset those inputs I get the errors again. I am going to try Bendandsends idea of individual install of debian 12.13.0 and Linuxcnc 2.9.8 and see what happens. I do not understand what you mentioned Tommylight when you said already replied to that from Bendandsend. Thanks for all you help I am frustrated now and appreciate all of the help to get this solved

I sat for some fifteen minutes and tried my best to make the xhc fail. The errorhandling branch.
It works fine. The movement I used to make it fail is now blocked. And for the rest I just works.
I tried things that takes a bit of time like switch screen that used to be a problem.
Not a proof it always works, but I am unable to make it fail.

 

In LinuxCNC, the XYZ tool offsets applied via G43 work correctly for the tool.
You can apply them inside M6 by executing G43 inside remap, or separately — it doesn't matter.



The error you are receiving indicates that you have changed the tool orientation (rotated the WCS). The post-processor checks whether your MachineConfig can perform an ABC coordinate system rotation, but you most likely have a standard 3x configuration.

However, to use drilling in planes other than XY (G17) without WCS rotation, you will need to change the post-processor logic in Fusion 360. The standard LinuxCNC-EMC2 post does not allow this. The standard 5x or 3+2 post will not work either as they rotate the coordinate system, which is unnecessary when drilling in a plane other than g17.

There are different ways to implement this:

1) Classic 5x/TCP rotates the coordinate system by controlling the AB axes and TCP activation codes — this is probably too complicated for your machine.

2) Allow tool vector orientation other than Z – this is often used for rotary/angle heads on milling machines.  To do this, you need to modify the postprocessor. See this topic for more information: forums.autodesk.com/t5/hsm-post-processo...n-stock/td-p/8911668

In this case, you do not need to select 'Tool orientation' in Fusion; WCS remains the same as in the setup.


3) The strange but common logic of posts for some furniture machining centers with drilling blocks that you can find looks like this: the g54 offset is defined for the XY machine plane, other offsets are used for side surfaces, and then the CNC recalculates. The control program looks like a cardboard box unfolded onto a plane. I don't think you'll want to use this strange proprietary logic.


I recommend adding mandatory checks:
In the post-processor:
- Check which tool numbers can be used in planes other than the XY plane.
- Check that side tools (T for the ZY plane) are only used for operations on the ZY work plane.
In the CNC:
- check that the XYZ tool offsets for side tools are not equal to 0 (this check can be performed inside M6).

See if you can find something in Australia, otherwise Europe (Germany and Portugal) or USA.
Portugal uses DHL for all their shipping, so it is fast but will cost a bit more.
Portugal
www.eusurplus.com
Germany
www.welectron.com
USA
www.mesanet.com
www.mesaus.com