Advanced Search

Okay, thank you for the feedback. I realize now I wasn't clear in my last request, but I meant jogging with the pendant while a program is running. But you did that as well.

This setupAsyncTransfer() assertion failed is also what I had before changing the loops. That error occurs when the USB dongle has already reset, most likely because it saw no activity from the computer side.

I mentioned that after some time, the pendant still stops working for me. But I don't recall right now if I have even checked if I get the same setupAsyncTransfer failed at that time. I should check...

If you continue using this modified version, let us know if it looks to have cured the other issue you had as well.

I just started on writing a new firmware for the dongle. But I'm not sure where that will lead, if anywhere.

I will measure the Mesa output signal again and compare them with the running USB-Dongle signals.
Maybe there is something wrong with these PullUp/Down resistors.

If there is any output, it could be the wrong configuration.
If not, maybe something is wrong in my .hal
Is there any chance to see the pktuart output in terminal ?
Like wireshark or candump ?

Thank you!

Congratulations on the project, the PLC + LinuxCNC integration looks really nice and the machine layout seems very well thought out and organized.

Looking at the machine layout (heat press laminator, 4-axis CNC cutter, pallet transport, and the overhead projector), I was curious about the main application: is it aimed at processing sheet/panel materials in general (plastics/polymers, MDF, composites, laminates), or is it focused on a more specific material or process?

In my case, I’m working on a different kind of machine, more focused on laser cleaning and painting, with a modular gantry-style structure (about 2 m modules, extendable up to ~16 m on X, with ~2000 mm usable Z and ~300 mm Y). So it was really interesting to see how you handled the integration and the production flow in your system.

Regarding the integration approach: I started by trying to validate the same PLC-as-master / LinuxCNC-as-motion-controller model using mb2hal / Modbus directly, just to keep things simple and close to the field. In practice, I ran into some interoperability issues with the specific setup I have (mainly around protocol framing and what the HMI/PLC side actually exposes as “Modbus TCP”).

In the end, I validated the architecture using a Python bridge as well, but instead of Modbus TCP I used OPC UA as the integration layer between the HMI/SCADA side and LinuxCNC. With Python (using an OPC UA client library) talking to a running LinuxCNC instance, I can exchange status, commands, and recipe parameters in a very similar way to what you described: the operator never interacts with LinuxCNC directly, everything is driven from the HMI/PLC side, and LinuxCNC stays focused purely on motion.

Conceptually, the control model ends up being very close to yours: PLC/HMI remains the master, LinuxCNC is the motion controller, and the Python bridge handles the handshake, heartbeat, status propagation, and command flow between the two worlds. The main difference is just the transport layer (OPC UA instead of Modbus TCP) due to the constraints of my current hardware/software stack.

By the way, for systems like yours, do you usually integrate them with a SCADA layer, or do you prefer to keep it as PLC + HMI + LinuxCNC only? And if you do integrate SCADA, have you ever used or evaluated any open-source solutions?

Thanks again for sharing the real-world experience — it’s very valuable to see these hybrid architectures working reliably in production for years.

Tested today, but not very conclusive I'm afraid.

Default master branch.
Jog while running Gcode: Doesn't allow me.
First time running gcode, press stop. While in Auto mode spin the wheel: It crashes see screen dump below.
After restart and retry this several times: It works, it switches to Man and moves in Z.

With loops=10, it always works, at least the say five times I tried so maybe not conclusive.
I can continue with this setting to see if it fails later.
 
I always get this "assert" error when it fails.

Soooo, this new frame makes the old one look like a carvera. Sorta shocking. Hurry up with that jerk limiting.....

 

Thanks, Rodw, looks great! 
I really need a bigger faster 3d printer, my Elegoo Neptune Max gantry type printer doesn't always fit my projects... I'm inspired by an FLSUN S1 that I watched printing one day. It runs delta kinematics, and it runs so fast the print head is just a blur. Pretty much sounds like a clothes washer in fast spin cycle when it's printing.

I'm playing around with dimensions a bit. In my 3d sketch, the linear rails are 2000mm long and will be attached to the steel frame (not shown). The round build plate at the bottom is 750mm diameter. The delta legs carrying the print head will likely be aluminum round tube.

It will be enclosed and heated, build plate will also be heated. The three delta motors will be up on top outside the heated enclosure, driving the carriages up and down via gear belts.

The door will be something like polycarbonate. Two thirds of the sides will be sheet metal heavy enough so it doesn't sound like a tin can, that steel shell will probably be the main frame. One third of the sides will be the clear door spanning most of the distance between two rails.

I do not yet have any mass measurements for calculating speeds with. I will be happy if I can make it go faster than my Elegoo printer. I don't expect to win any races with that FLSUN S1, that thing looked like its delta legs might be carbon fiber.

According to downforeveryoneorjustme.com/ it has been down for everyone a few times lately.

If you use shielded tips so the bare electrode does not connect the material, I would use a second THCAD for material probing.
ONe user here stated it was crazy fast and saved a lot of time...

There you go. I've spent a few hours today updating this to add cutting forces as it was initially built for plasma table design.I don't know what kind of machine you are planning but I have put it beside my drive X (yours is Y, Z ignore.)This is based on the work energy method and assumes a 3 second cut with a 1% trapezoidal profile. eg 1% accel,  (98%) cruising and 1% decell at a cut speed of 5000 m per minute. 150 N cutting forces. Assumes a 45mm dia pinion (40 tooth Mod 1.25 gear) with 5:1 gearbox they don't seem to make a 30mm (20 tooth) pinion for a 14mm dia output shast which is the normal  one found on a planetary gearbox.It draws a trapezoid profile of the test cut.I almost left your power supply at 24 volts as it actually would do the job for those specs. I put a derating to 24v in and it shows no reduction. But it halves the available power to the same as my 2 amp motor @ 48v. So the sheet goes through all of the physical power and torque requirements

We calculate motor Average power and RMS power. I would use Average power with cutting forces. This number must be less than the available power  lists further down

So we can see that your drive under these conditions only needs 2 amps RMS at 22 volts. Further up there is a magic ratio, the System to Rotor Inertia Ratio. It should be 1:1 but not exceed it. In your case, its massively oversized for my project. And so is mine but the price is right.

Finally, we calculate the ambient heat rise. It must not exceed the drive's rating which is usually around 130 deg C when the insulation could melt. SO you can see that is not an issue and that 100deg C is usually safe.

So all in all both motors simply idle and will never be called upon to exceed their available power at which point you could loose straps. SInsummary, they can run 24/7 without the risk of loosing position!

my1987toyota wrote:

Does anybody know if the forum was actually down or is the USA starting to limit how it's citizens can interact
with others in the world? 

It's down for me as well regularly... in the USA.

QtPlasmaC updates - Master (v2.10):

• refactor button interlocking
• fix laser button state if bounds error during laser dry run

There is some mismatch with the numbering.
The pattern is lcec.<master idx>.<slave idx>.halPinName
master idx is always 0 for you. Slave idx is 0-3 in ethercat-conf.xml
but 3-6 in the hal file. They must agree.
Go through the hal file and compare with ethercat-conf.xml so you
refer to what you intend to.

Oh, wait! There is the name="D1" field used. Then the hal pin is called lcec.0.D1.halPinName.
With that info, rename the lcec variables in the hal file. D1, D2, D3 etc.
Many of us use a descriptive name like X instead of D1 and so on.

I'll add the missing pictures / manuals here since i could only attach 8 to the original post.

tommylight wrote:

Can you post from a phone or a tablet?
 

Ich habe es heute getestet, denn das Forum war wie so oft nicht erreichbar. Es war auch nicht vom Handy oder Tablet-PC aus erreichbar! 

So i changed that and it still shows the same thing