Advanced Search

If anyone uses Vismach and would like to test this out, please let me know.

I'd be _very_ interested indeed. Do you have a repo?

You might be interested in testing the currently ongoing work on multi axis features:
github.com/LinuxCNC/linuxcnc/pull/4374

it will be a cobot

Nice project.

But the wrong name? That a robot and not a cobot?

Hi LuxCNC, Hi Rod!

thanks for your hints!
setp hm2_7i92.0.gpio.019.is_output 1 did the trick for me!
Honestly, i thought i was through with the obvious starter-issues, but as i learned, not by far!

Thanks for the hint with inverting the pwm, i will have a look at it!.
Also the "spindle-rpm-reached" will be part of the ongoing process!

Greets, Tom

And here is how it looks with the enclosure mounted on the table.

 

With all the mechanical bits in place I wrote a short spindle run-in program that increased the spindle rpm in increments of 500 up to 6000 and ran for 10 minutes at each increment.

Everything worked well until I reached 5000 rpm when the spindle servo threw a fault. Turned out I had the max allowed rpm set to 4500 in the servo drive since my old spindle couldn't go that high.

Fixed that and immediately ran into the next issue, the default rpm limit for the encoder speed in the servo drive also had to be increased. In the end I had to bump up quite a few parameters including tweaking the inertia to get the full 6000 rpm range enabled in the drive.

The next issue I ran into was that the rpm would not go above 5610 when commanded from LinuxCNC. Turned out that I had to adjust the settings in LinuxCNC regarding how many steps (pulses) per seconds that could be sent to the spindle. Just as with the drive I had set these value quite low for my old spindle when I did the configuration years ago.

With all that sorted I could finally finish the run-in program. But when the program stopped after running the final increment at 6000 rpm I ran into the next issue. The drive threw a fault regarding an overheated regenerative braking resistor.

Going from 3500 to 6000 rpm along with the increased the inertia from the larger spindle overwhelmed the built in regenerative braking resistor in the spindle drive when coming to a full stop from 6000 rpm. I managed to get it somewhat working for now by increasing the time for the spindle ramp down by a few seconds.

But if I stop the spindle a few times in successions from full rpm I still get the fault. So I ended up ordering an external 800W braking resistor which should be here early next week.

 

If I managed to follow the formulas in the Delta B3 manual correctly a 550W resistor should be enough for my setup. So hopefully 800W will give me plenty of headroom.

However after all the troubleshooting I was still very satisfied at the end of the day when I removed the BT40 tool holder which had been in the spindle all day running at various rpm's. It was essentially the same temperature as when I had picked it up from the tool shelf in the morning.

The new spindle is running significantly cooler compared to the old one. This can also be seen on the idle load.

With the old spindle I would have an idle load of 17-20% on the 2kw spindle servo just running idle at 3500 rpm. The new spindle sits between 1-6% depending on rpm, at 6000 the load is just 1-2% which is very promising.
 

Hi everyone,
I’m building EgeCobot, a custom 6-axis collaborative robot arm powered by LinuxCNC and EtherCAT.
I’m writing my own custom kinematics component for LinuxCNC to handle trajectory planning and joint control for this 6-DOF setup.
Here is the first video introducing the project and mechanical layoutlanned Tech Stack:

* 6-DOF articulated cobot design
* Custom LinuxCNC kinematics module
* EtherCAT fieldbus for real-time joint control

I’d love to hear your feedback and suggestions on EtherCAT setup and HAL integration!
Best regards,
Emre

snowgoer540 wrote:

I wonder what the cause is. Part of me thinks people have moved on to laser since it's become more affordable.

Yes, exactly, here the government payed 15K Euro to china for everyone working with metal that applied for the grant to buy a laser and they added the rest, so basically killed off my business completely.
Not the only business, so i was not worried ... till the PC market went bananas with prices skyrocketing, so no more PC builds for now, and in the near future by the looks of it.
3D printing business was not that active, but occasionally it would bring nice revenue from people with bitcoin miners that needed cooling adapters...
I am ranting again ... sorry.

tommylight wrote:

Sorry Snowwy, i should have also mentioned that on all my other machines (probably 20? Plasma's) positive limit is at 0, and the example above was for very old PlasmaC, not QtPlasmaC.
On "my Red" machine (my refers to the one i use often, not the rest of them), i still use old PlasmaC and new QtPlasmaC, as my clients have both types in use so i can not afford to forget how to use them, technical support being the main reason, and testing new versions being the other reason, as you can notice if you watch my videos on youtube, different PC's and laptops but always the same red machine.
I am also sorry for not helping more, but as i mentioned several times by now on the forum, work has plummeted badly, been probably over 5 months without turning the machines on.

No apology is necessary!

Sorry the work is plummeting. I do think there are WAY fewer people making plasma tables as compared to when this part of the project was in its prime. I wonder what the cause is. Part of me thinks people have moved on to laser since it's become more affordable.

Sorry Snowwy, i should have also mentioned that on all my other machines (probably 20? Plasma's) positive limit is at 0, and the example above was for very old PlasmaC, not QtPlasmaC.
On "my Red" machine (my refers to the one i use often, not the rest of them), i still use old PlasmaC and new QtPlasmaC, as my clients have both types in use so i can not afford to forget how to use them, technical support being the main reason, and testing new versions being the other reason, as you can notice if you watch my videos on youtube, different PC's and laptops but always the same red machine.
I am also sorry for not helping more, but as i mentioned several times by now on the forum, work has plummeted badly, been probably over 5 months without turning the machines on.

A couple of photos would help as I don't understand what you have done
Normally you would use 0-10 volt from the VFD itself.
Your VFD will have several terminals on it that need their function set, I have X1,X2,X3,X4 that can be programmed for specific functions
A 5v relay either on your BOB  or an external one will trigger forward and reverse. (I used X1,X2)
The VFD should also have a relay internally. You can program this to be "Frequency reached" or similar and send that back to LinuxCNC for your at speed signal.
The only catch I  had was I had to invert the pwm pin otherwise it ran the wrong way (eg S0 gave 10 volts). Not sure how Mesa does it. I recently published some videos on my YouTube @MrRodW channel about wiring in a BOB and how to set up the spindle.

I’ve recently spent a lot of time visualizing the workpiece in Vismach and optimizing toolpaths.
If anyone uses Vismach and would like to test this out, please let me know.

 

it's not that, zeroing out an axis in G54 offset (the default) wont do anything. the config isn't right. having a positive travel distance tells it there is 7.5 inches above wherever "home" is. the limit switch is at the top of the travel looking at the pictures. The first move is to go up to z max minus 0.196". which instead of being -.196" it's trying to go to 7.304.

This is all in G53 to be clear.

You can try something PhillC mentioned quite a while back when i was using non standard Z axis limits on my machine:
-jog Z axis down till the tip of the torch is just under the material/plate
-touch off Z axis to 0 there
do some tests, see if it works properly.
It did work for me, and most probably it is still like that.

The step/dir outputs should continue toggling indefinitely.

At this point I would ask for a RMA# from Mesa and return both the 7I76U and the FPGA card for
analysis/repair/replacement.