Advanced Search

Not sure about the analog input of your MESA hardware but it might be possible to use a MESA THCAD board which converts DC voltage to frequency and connects to an encoder input. But you would need to check if it is suitable for 3.3V

'M52 Pn' is Gcode so it would have to go into the Gcode program or be issued as an MDI command.

once you have the voltage (or frequency ) in HAL you can do all kinds of things including a PID loop to control the feedrate also a GUI panel should be trivial then.

Thank you, I am still far out from this project as I have not purchased anything yet, I want to make sure I know what I need and what I'm buying. I am currently learning about Ethernet ports with real-time operations and which PC to use for this.

I need someone pointing me in the right direction to get my spindle running.

I can either try to get classic ladder to work. For whatever reason, it will not work with Rio.

This is the code rio creates in the rio.hal file.
If I start LinuxCNC, it is not in Modbus Master mode. So I changed the configuration. This is what works on the same machine.

When I start LinuxCNC I get the following error:
I tried to remove the numS32out=100, but no success. I can load the program manually with the ladder editor, but it is still not in modmaster mode and won't work.

---

I could also continue to work on the Modbus integration. I know which registers to read and write from my VFD, but need some starting help to translate this:

 

Into this:
 
 

forum.linuxcnc.org/plasma-laser/54413-th...-will-kill-it#314239

Hi,
    Has anyone had experience hooking up a CUT55-DS to a MESA THCAD. I contacted Yes Welder, but they gave me the brushoff.
I would like some help if there were any for this model. 

https://www.bing.com/ck/a?!&&p=a103529438c4ea706a21eccd5af2cc56ad07ce8645277c56e1b0e38c5447441fJmltdHM9MTczMTg4ODAwMA&ptn=3&ver=2&hsh=4&fclid=20d478e5-c534-69ce-18ec-6dcbc4c468e8&u=a1L2ltYWdlcy9zZWFyY2g_cT15ZXN3ZWxkZXIrY3V0KzU1LWRzK2JsdWUmaWQ9MDcyOEYzNDM0RkFFMjFDNUEyRUNDRDM4ODg0REUzQTFFMjQ3OUNCNCZGT1JNPUlRRlJCQQ&ntb=1

For the Y axis, I pretty much stole the idea of the Gordillo Bellows: dynatect.com/product/protective-covers/bellows/gordillo/

The problem with those is they don't compress enough- I have very little clearance between the mill column and the table when at the limits of travel, and didn't want to lose any travel. So I made a simpler version. This is just a bunch of L-shaped pieces with accordion material glued between them- see previous post for how it looks in real life, CAD drawings attached.

There are two "tricks" to this- the first is to make sure that the plates overlap some amount when however many folds of accordion material is pulled taught. This helps make sure chips don't get under the plates and stuck between them (though the good news is that accordion material will still stop them from falling on your ways even if that does happen). You can adjust the size of the accordion material, the number of folds, and the geometry of the plates to get whatever extension/collapsed size/ratio you want.

The other "trick" is that this will collapse under its own weight- you need some kind of support. I just 3D printed some brackets to hold a couple 1/4" rods that the covers kinda ride on. The geometry was all eyeballed, so I'm not posting any files for that. You can see it in action in the pictures attached to the previous post.

You obviously also need some way to attach one end to your Y carriage and one to the mill column- that's machine-dependent. On my machine, I just used a chunk of C channel bolted to the column, and directly bolted the opposite end's plate to the carriage. The C channel is glued to accordion material and permanently attached to the L-shaped plate assembly.

Once again, these parts were made at SendCutSend out of 304 stainless. I bought 8 of them (turns out I only needed 7), and cost me $53. Ordering multiples of a single part gets you a discount. The 5' chunk of accordion material I think was ~$20, the glue was... I dunno. So call it $100 for metal way covers for the Y axis. The assembly was nothing special- scuff the metal surfaces, clean with acetone, then put glue/accordion material in there and clamp until dry. The glue I used was Loctite Extreme Glue, but I suspect any number of adhesives would be fine.

Files for the plates attached, though you may want to scale for your machine.

So far they've held up to stainless and aluminum chips, and kept the leadscrews/rails clean. Hopefully somebody finds this useful!

Thought I'd share my solution to way covers on my benchtop mill. Most of the suggestions I found were for leather, rubber, or accordion way covers, which all seemed suboptimal to me- they collect chips, or burn, or melt, or get in the way of leadscrews. I wanted basically the fancy sliding metal covers you see on commercial machines, but at a hobby-friendly size and budget. Especially something that didn't interfere with the already-limited travels on the machine. I came up with 2 different designs- one for the Z axis, one for Y (between the table and column). The attached pictures show them installed on my mill as a good overview.

For the Z axis, what I ended up with is a set of nesting panels, with the ends bent at 135 degrees so they dovetail together- so they're more or less constrained to only slide in one axis. This ends up being quite thin- just the thickness of however many sliding panels you need. You can see this in the PNG showing just two such nested panels.

The catch then is you need some way to make them extend and not just slide all the way past each other. The trick is that they edges are bent with a constant radius, not a radius that shrinks as you go further down the nested parts. That means there's clearance in the corners, which you can take advantage of. Hopefully the attached CAD files make it clear, but if you bend a tab outwards at the top of each panel, and inwards at the bottom of each plate, when they nest, each panel can almost slide through the next one further out- until the tabs bent outward at the top of the inner panel catch on the tabs bent inwards on the bottom of the outer panel. I unfortunately don't seem to have a 3D model of this, so see the second PNG with the added lines showing tabs. Hopefully you can imagine the red panel sliding down until it catches on the green panel's tabs.

The very top and bottom pieces are the same, except with whatever additional pieces you need to attach them to the Z carriage/spindle and column. You can see what I did in the picture below + CAD files, but it's machine-specific. The two cap screws you see at the bottom are there to stop the panels from falling off the bottom and interfering with the Y axis.

For what it's worth, all of this was designed around SendCutSend's capabilities- their bending method leaves a constant radius, which is perfect for this. The 4 panels for my mill were $114, made out of 304 stainless. Amazing, IMO. The .zip contains the STEP and FreeCAD drawings for my machine's Z way covers. You'd need to adjust sizes/attachment to make it fit a different mill.

(will put Y axis details in next post)

Aciera,

Thanks for the response. 


First and unfortunately, I told you wrong.  The Powercore is not outputting a HIGH or LOW signal but a PWM signal.  Here is a excerpt from the GitHub:

“The Powercore V2.0 provides digital telemetry on the spark ignition rate via the ALRT port. The spark ignition rate, defined as the ratio of 'observed discharges' to 'possible discharges'. The spark ignition rate is a key indicator of feedrate efficiency. A low rate suggests the feedrate can be increased, while a high rate indicates an excessive feedrate or a short circuit. Telemetry is reported as a PWM duty cycle, which can be read by a control board or microcontroller. This port enables closed-loop feedrate control, ensuring optimal material removal. An ignition rate of approximately 80% has been observed to be optimal.”

Here is the link as well: github.com/Rack-Robotics/Powercore-V2.0


So I have a few thoughts.  First is hardware compatibility.  My machine is running on a Mesa 7I96S and a 7I85S.  The 7I85S is essentially unused right now. I am looking through the technical documents and it seems like the 7I85S has ports that can be designed as PWM output ports.  I am not sure if they can be configured for input though.  Perhaps you would know?  There are also a bunch of unused IO ports on both boards, but the technical documents don’t specify if those ports can be used for analog/PWM.  The Powercore also doesn’t specify what the voltage would be at 100% duty cycle so I am wondering if it will be compatible with the Mesa in that regard.  I suppose if the Powercore is opporating at 3.3v and the Mesa is operating at 5v for example, a multiplier could be added to the input. But if the voltages are reversed there could be an issue of overwhelming the Mesa or damaging it. 

If the Mesa does not have a PWM input, it seems like the next option would be to use something like an arduino to interpret the PWM signal from the Powercore and then talk to the Mesa via serial communication.  This sounds like a can of worms…


Second, software.  'M52 P1’.  Does this need to go into the main hal file? I assumed I would find 'M52 P0' somewhere but I did not.  So maybe it is currently on the default for my machine..  My machine is called the hackbot. So it would go somewhere inside the hackbot_srt.hal file? And then would the float variable go into this file as well? Plus whatever logic/code needs to be written to account for the above info from the GitHub (changing the federate based on PWM)?  Sorry, I can talk hardware all day long but software I am slow with.. 

Third, interface.  It would be really awesome to have a widget or something on the GUI that shows the PWM spark rate.  This is obviously not necessary but it would be very classy.  I have no idea how to do this… 

Also, it would be very cool to have the machine responding to the PWM and updating the feedrate to keep things at the perfect 80% duty cycle.  But if this is too challenging, it could be kept at default federate unless duty cycle goes over some limit (maybe 95%) then federate is briefly reversed. This would also make control via an arduino (or something else) easier as the arduino can just output a high or low which will avoid serial communication…


Thank you for the help. 

Best,
-Dylan

You might take the feedback out of the spindle mode system for debugging
by setting the velocity PID parameters all to 0 except FF0=1.0

So... I go to reattach the Y servo so I can run the tests mentioned above, and... the bloody nut retaining the screw is loose?!?!? Apparently I somehow missed that despite specifically checking it earlier AND pulling on the axis and not seeing motion on an indicator. Not seeing a beating-head-against-wall emoji, so you'll have to imagine one.

This might be an easy fix... well, the machine at least. The operator/debugger might be a lost cause.

Still going to try to mitigate the electrical noise and replace the ballscrew either way, still going to run tests.

(also definitely owe the forum a writeup on my way cover design as a thank you for the help- I've been pleased with them. Way better than the accordion/leather/rubber suggestions you typically see, much more affordable than the sliding covers you see on industrial machines, all while being nice and low-profile for machines without travel to spare)

ETA: Writeup here, may be clear as mud: forum.linuxcnc.org/show-your-stuff/54503-metal-way-covers

now the orientation works well but still no closed loop spindle control. at 1000rpm commanded it rotates 2600 rpm and that matches what i can see in halshow.  

Assuming the mechanics are good just because I built it myself is possibly not warranted That said, aside from the ballscrew I already ordered a replacement for (will probably take weeks to get here, though), I do believe the mechanics are in good operating shape.

From an electrical perspective, I'm getting an order together for ferrites and some PSU filters to cut down on noise- a lot of the noise seems to be coming from (or through) the power supply. Catching it at the source is better than trying to band-aid further down the line.

Those are the two things I know are suboptimal- fixing them may or may not be related to this problem, but definitely aren't going to hurt.

I'll hopefully get a chance to re-run the code tonight/cut air on the existing workpiece, and will report back when I get to that. I'm thinking I'll put masking tape over the -Y pocket surfaces. If the machine behaves, those shouldn't get touched. If cutting air looks OK, I can repeat in a fresh block of material. I also intend to remember to grab a screenshot of where LinuxCNC thinks it was cutting- forgot to do that last time.

I'll dig up a Windows PC to monitor the servo while I do the above and just jog the axis around. Thanks @Teknic_Servo for reminding me that's an option.

Gcode attached. I cut a couple operations from the end that I never ran, so what you see is everything that was run on this pocket. I've looked at it 5 ways (verifying coordinates in the code, viewed in LinuxCNC, FreeCAD gcode viewer, FreeCAD cut simulator, and some online viewer) and not found any issues, but would love for that to be the problem.

7i96S will do just fine.
Did you check www.eusurplus.com ?
And what is your native language? There are sections of the forum in a lot of other languages if you have difficulty with English.

stepconf doesn't know how to setup a step/dir spindle so I would
setup an unused axis for the spindle, and then edit the hal/ini files.

If you do that and post the hal/ini files, I can give you some direction
in what needs to be done.

In the last line of "remora-eth-3.0.h" from the remora component the default line is:
#define PRU_BASEFREQ 40000 // Base freq of the PRU stepgen in Hz

Try to increase that frequency and recompile/install

And a quote of Scott: "Your joint max velocity needs to he higher than the overall max velocity so that a joint can try to catch up the following error."