Advanced Search

As I mentioned earlier, in FlexGui, the Z-axis = 2 on a milling machine, and on the lathe, Z = 1. If I change Z to Y in the ini file to the following:
KINEMATICS = trivkins coordinates=xy
COORDINATES = X Y
[AXIS_Y]
Then I can jog the Z-axis after homing, just as it’s supposed to work,
but of course the lathe won’t run because it requires XZ.
So now I hope you’ll make the necessary changes so it works correctly.



 

Still buggy but here is a direct open source ripoff of Fusion - Its only CAD now and looking at it, it violates every design and copyright that Fusion probably holds. But how in the hell are they ever gonna stop them?

Frankly, despite the bugs, I'm picking my jaws off the floor - its that good already.

solidcraftcad.com/
 

CSV, CSP Configs added:

github.com/szolkaa/Automatic-linuxcnc-co...erators-for-ethercat

For exampleinstead ofMore work, but better results
 

First of all, I would like to remind you about something that is obvious and should not be discussed.
A CNC machine is not a toy. Even a small desktop milling machine can destroy valuable material or injure the operator. Therefore, all important controls should be clearly visible and easy to find and use, even when the operator is surprised, tired or nervous. Aesthetic preferences are always secondary.

Now to the point.
I have never been interested in the appearance of the interfaces I used (previously Axis, now Gmoccapy). I assumed that if the author liked it and I can use it, there are more important matters. (That's why I don't know many things and I will probably try to force open doors...)
But today a serious problem arose and I had to look into it
Well, I started configuring the milling machine with xyzab_tdr_kins kinematics (five-axis with switchable mode).
And I see something like this:
 
This is the code M428, not M4 28 (!!!)
I started searching and found nothing. As if the authors wanted to keep it a secret... But after some time I came to some conclusions.
The default Gmoccapy setting looks like this:
 
And it works like this:
 
 
The second image is in program execution mode. Why the hell do the parameters change from black to gray, I'll probably never know, I assume the "artist" who came up with it liked it so much...
I haven't found the file responsible for this display parameters anywhere, I must have been looking in the wrong place or wrong name, but I shouldn't be looking for it at all, because it should be in the documentation.
I found the gcode.lang file, which is probably the only one existing in LinuxCNC sources. If this is indeed the case, it is also the only file on which the authors of LinuxCNC as the only ones have influence and no one will mess anything up without their consent and knowledge. And if this is the case, why is the default g-code theme set to "classic" and not "gcode"?
As for the gcode.lang file, it is far from perfect, but it is there, so it can be improved. First of all, the user can map any g- or m-code using REMAP in the ini file and this must be kept in mind when creating matching patterns.
 

My suggestion is to work on the gcode.lang file and set it as the default one.

Now that most of work which came with moving is done its time to finish the reason why I bought this machine in the first place...
The 4th Axis. The servo is running, so it's time to finish the brake, lubrication and homing. Then using the chance to also install the tool setter.

Also using the chance to update the scematics

now I am waining for some additional pins for the Harting connectors 

Then making a small junction box, so the A-Axis can be easily removed 
 

I would definitely post the two odd hm2_modbus behaviours as issues on the LinuxCNC github site.

Hi Peter,

as promised, here are the results of the bench test with all PktUART instances working at the same time.

Setup:
- LinuxCNC 2.9.10 uspace, Debian 13 PREEMPT_RT, Intel N150 (fixed at 800 MHz), hm2_eth, servo thread 1 ms
- pktuart.0 (TB2): on-board transceiver
- pktuart.1 and pktuart.4 (P1): small SP3485 auto-direction RS-485 modules, no TXEN pin
- 3 x StepperOnline A6-RS servo drives, one per port, Modbus RTU 115200 8N1, addresses 1/2/3, rxdelay 40 / txdelay 45 / icdelay 20
- pktuart.2 <-> pktuart.3 cross-connected at logic level; a small RT component on pktuart.3 acts as Modbus slave simulator (with fault injection) or as full-duplex loop partner
- in total 4 hm2_modbus instances in parallel plus one extra PktUART user
- test tooling vibe coded with Claude

Results:
- Endurance: one run of 2 h plus two earlier runs of 30 min each. The 2-h run had about 3.3 million Modbus transactions with 0 errors on all instances. Cycle 8 ms per drive (2 registers + status), 11 ms for the simulator. Servo thread tmax <= 260 us, no watchdog bite.
- RX masking without TXEN works with the auto-direction transceivers on P1, no echo problems.
- Isolation between ports: unplugging a cable, swapping two cables during operation or adding 1 ms response delay only affected the instance on that port. The others kept running without errors.
- Fault injection: timeout (110), CRC error (52), late answer (110) and exception (74) are detected correctly, only on the affected instance.
- Watchdog bite: all instances report a fault. After clearing has_bit and pulsing hm2_modbus.N.reset all ports run again, no PktUART reconfiguration needed.
- 9600 8E1 on one port next to 115200 8N1 on the others: no problems.
- 60-register read: 20 ms, 0 errors.
- Full-duplex P1 port (drive enable set statically, 2.5 and 5 Mbit/s): 1.8 million frames, 0 bad, 0 lost, while the Modbus instances ran in parallel without errors. My component counted one framing-error flag right at each session start, probably start-up, not investigated further.

Two hm2_modbus behaviours worth knowing (2.9.10, not related to the bitfile):
1. After 5 consecutive errors a command is disabled. It stays disabled even after the device answers again, until there is a rising edge on hm2_modbus.N.reset (or command.NN.reset). So an application needs its own reset logic.
2. An answer with a wrong slave address is not counted as an error, it is only logged and the request is resent (hm2_modbus.c, around line 1780). The HAL value then freezes silently while errors and fault stay 0. I monitor the age of each value for this reason.

Are these behaviours intended, or should I report them as an issue?

Limitations: bench setup only. Motors not energized (no PWM noise), short cables, one device per port. I have not run a test longer than 2 h with all ports in parallel.

So far the bitfile looks solid for my use case. Thanks again!

Thorsten

I'll be using my Claude Code / Fusion to recreate the demo example, then if that goes well I may attempt a fairly simply layout that I was planning to do myself.

Like others, I've spent hundreds, perhaps thousands of hours of my life doing PCB layouts over the past 50-odd years, either personally or sitting alongside CAD jockeys. Good layout artists are a rare breed, yet few experienced engineers fancy spending their time simply laying out boards. If these agents can successfully acquire that knowledge and experience, perhaps we can end up with tools that deliver robust designs in record time. That's how technology moves forward in leaps and bounds.

NWE wrote:

Just today someone showed me a video of the latest Tesla car. Almost like science fiction but it is for real.

It is not real.
How can you believe that is a 2 ton car doing that?
That is a 20-40Kg heavy something that looks like a car.

@Muzzer introducing Hydrogen electronics prototyping.
Now THAT blows my mind.   Finally I run into an ai project that genuinely shocks me. I have spent many hours designing PCBs using KiCAD. Seeing the Hydrogen capabilities nearly makes my hair stand on end. I might cautiously try it out sometime.
Exciting times!

I think now I better understand some professional software developers' reactions to the ai craze, now that I personally see ai help draw a PCB. Can ai really get it right? That fast?

Just today someone showed me a video of the latest Tesla car. Almost like science fiction but it is for real.

NOT my stuff!!!
-
Bumped into this, clearly showing the reasons and the difference it makes using twisted pair wiring, especially for us using machines in high EMI noise environments with all the Plasma sources and VFD's and servos.

NWE wrote:

Same here. When I was new on Github I thought I could fork a project to my account to archive it. Nope one day I came back and discovered my unchanged fork had vanished along with the original author's interesting project.

GitHub is property of microsoft, and as luck would have i bumped today on a project that no longer exists there.
Bit by bit disappearing... and being used in windows as proprietary code. As is over 60% of win11, 45% of win10, etc etc from the network portion of Linux showed into win2k back then.

There is another version of the electronics stuff that also does boards and routing, but still in infancy, getting interesting for sure.
Damn it, i wasted countless days doing electronics when i was young, had to wait till summer to go to Croatia to buy parts and books and magazines, yet it never stopped me from doing ... everything. Youth today can not figure out how to open a barn door!
But can easily figure out how to press 20-30 times on random stuff on the phone to start a useless game!

Within the space of 10 days, there is an embryonic clone of Fusion bubbling away. No CAM yet - but give it time (another week??!).



What is staggering is how rapidly this stuff is coming out - and almost from nowhere.

And on a slightly different note, if you do your own circuit and PCB design, there are some pretty interesting tools coming along, also free to use:



Give these tools another year or two and they will become much more robust and dependable. Exciting times!