Advanced Search

Im an electronics technician located in Denmark with an hobby interest in mechanical design, cnc milling and additive manufacturing.

A couple of years ago I bought an cnc router with zero experience in the field. The building and electrical parts where a breeze and the grbl controller that I bought back then was an easy thing to flash with fluidNC and get going. 

Now I'm going into more advanced features and adding an self designed atc system hereby arose the need for a more capable controller. The choice settled on the Mesanet 7c80 due to form factor with the rpi and the number of i/o without the need for an daughterboard.

I have experience with rpi/arduino/esp32 projects and have worked a limited bit with commercial fpga cards before.

I have never worked with Linuxcnc before but settled on this environment and the mesa board due to:
1. active community 
2. Full customization

So the big question is, where do I begin? What would be a good course of action to get going in an orderly manner? 

The hardware:
clossed loop steppers and drivers
XYYZ + AB (possible used to manipulated the ATC later)
inductive sensors on all axis
several solunoidvalves (mist and air)
several relays (pumps and spindle light)
surface probe
tool lenght sensor
several failsafe and e-stops
ballscrews on all axis

The atc system will be an add on later and will not be a part of the initial setup.

The electrical part is going to be an non issue for me I have already planned this from the drawings in the 7c80 manual.

Thanks in advance



 

Hi Atlantis, did you solve the tool change procedure? I a also working on setting up a emco vmc100 and struggeling with the exact same problem

thanks for your advice.
 

Custom kinematics is likely the best way to go about it. I would recommend to use the 'userkins.comp' template as it can be installed using the 'halcompile --install ...' tool:
linuxcnc.org/docs/stable/html/man/man9/userkins.9.html

I can't thank you enough for your effort. This is a real time saver, I've spent hours just to understand what's behind a possible implementation of an atc.

Guess PB is going to be one of the most used GUI because it is cutting all the hardest parts to setup.

The strange thing is I haven't ran an update for quite a long time.
I have been doing a lot of configuration work in HAL and INI files.

I will check with meld, create a backup and perform an update anyway to see if it fixes the problem, thanks!

For troubleshooting, comment out the hal lines that connect pyvcp pins (ie those line that create errors) then start your config and use the 'Show hal configuration' tool to check if the pyvcp component has actually loaded and if it has what pins have been created.

It is possible that hal_gpio is not working because libgpiod is not installed

What does: sudo apt-get install libgpiod say?

Is there any indication of something working when you press the macro button?

What does this line mean? (doesn't seem valid to me)o<hal_value> include "/tmp/gcode_var.ngc"

Hello everyone,

I am currently setting up my plasma cutter and encountering some initial issues that need resolution. One of these issues is the intermittent loss of my THC encoder signal, which occurs briefly at irregular intervals. Aside from this, the signal quality appears to be satisfactory in terms of noise. When the signal is lost for a few milliseconds, the torch attempts to compensate by raising itself before leveling again. I have attached a photograph (apologies for the quality) that illustrates the signal drop, followed by a voltage increase caused by the raised torch before it levels again.

I am utilizing a Beckhoff EL5101 incremental encoder interface in conjunction with a Mesa THCAD2. I have also tested with a THCAD300 I had available, and the issue persists. Additionally, I am employing hypersensing with a second THCAD2 and another Beckhoff EL5101, exhibiting the same behavior. Given that I previously used the THCAD300 with a 7i76e without issues, I suspect that the Beckhoff modules might be the cause.

Attached are three screenshots: one showing arc voltage at 0V, another displaying encoder frequency initially at 0V and then at 12V for testing purposes, and finally, the problematic screenshot showing encoder frequency during cutting. What options do I have to filter these signal drops effectively?

Thank you in advance for any advice or recommendations.

You shouldn't need to use stepconf at all, the original configuration files should just work.
In fact you should be able to open even a version 2.7 or 2.6 configuration and the system should update the HAL and INI files to work with 2.9.

Lcvette nice.. have you considered simply adding the probing tool number parameter to the toolchange call with an if statement? this way anytime you load or unload the probe tool it would activate a subroutine to either deploy the probe or retract it?
 
Great idea, that should work perfectly..... thanks!

Lcvette Interesting concept on the ride along design. that is going to add quite a bit of unbalanced weight to the machine maybe? have you considered how that will affect high speed motion and inertia differences for the slaved drive motors?
 
Yes, I did consider the difference in inertia, altough I didn't go into calculations for this. 
The motor on the side of the toolchanger will have to work harder on accel and decel. For accuracy or chatter I don't think it will do much, as it's directly mounted on the beam which is also connected to lineair rail and 20mm ballscrew ( ballscrew on each side).
With routers, the Z assembly could anyway be all the way on the side and is even heavier. It does add up ofcourse... 

The weight is not too bad, the plate diameter of the carousel is 200mm and I use ISO20, so quite compact.
I could make the construction lighter by milling some pockets if needed.
Typically I jog the machine at 12000mm/min and 1000 accel/decel, but am machining at half of that at a maximum so there's some room too dial it down still should the need arrive.

Lcvette I am about to release a fully integrated RACK type atc integration for probe basic, this could be a simpler and more economical method for atc maybe?
 
The problem is the rack type will make me lose work area, and I need the full Y axis range.
I build the router to cut moulds for composites (hydrofoils) and boards, and when I started building the router I thought 1000 x 1640mm would be fine. But the boards are longer now and my work area is already 10-20cm too short.

I am not completely clear what you want to configure, but my own lathe has a three-position switch for coolant on, off and auto (in "auto" mode it runs according to the G-code flood coolant command)

I use a "mux" component. Specifically an 4-way bit-type mux_generix:
linuxcnc.org/docs/stable/html/man/man9/mux_generic.9.html

Basically if no sel inputs to the mux are set the it passes-through coolant-flood.
If the force-on input is set then hard-coded to on input 01 is used
force-off uses a hard-coded off.
The switch isn't capable of sending both force-on and force-off inputs, but I set that combo to 0 just to be tidy.

Ping times of 0.5 ms are close to unusable

Do you have 

hardware-irq-coalesce-rx-usecs 0

in the interfaces file?

This is needed if you have a Intel Ethernet interface chip
 

the new implementation of the rack atc will handle all toolchange motion. i just finished working out the user parameter setup page, this will give users 8 unique machine mechanical rack row configurations to successfully implement directly from the rack setup page in the ui.  i wrote a subroutine that will calculate which rack ID type based on 3 user XY machine coordinate position inputs for the center point of (pocket 1), (pocket 2) and (pocket 1 clearance).  that rack id will be used in the remapped atc macros to dictate all of the motion and directional requirements for knowing which direction the rack is positioned on the machine, (along X or Y axis), which direction the pocket numbers are ascending from pocket 1 position, and which direction to remove the tool from the fork.  this along with an ini setting for the pocket count, the traverse feedrate for the atc motion, the z clearance height and z load height will give the atc macros the required motion parameters it needs.

users will still need to properly setup their hal for IO such as drawbar, spindle orient, any safety sensors etc, but this will get the user an easy to use atc with minimal setup difficulty!

 

 



 

Thank you for the quick reply, I do appreciate it.
The gui does load for about half a second and then closes with the error. I have put the connections in the custom_postgui file but I'm getting the same result.