segoman-designs
SegoMan DeSigns
Sounds like there is some homework that needs to be done on this...
Plasma workflow thoughts after testing LinuxCNC/QtPlasmaC
- Thread starter fablab
- Start date
Could you elaborate on what the solenoid actually do?
Most plasma don't operate solenoid valves as part of the plasma cutting process which is why I said you wouldn't need to use M62 / M63 but your machine must have some additional cuttings features not found on other machines.
Note: solenoids used for scribe and drill position do not count as there are automated for as part of the Tool change process.
My understanding of Lillow's THC unit is that it is a standard Up/Down THC utilizing the M667 & M666 Gcode commands just like a Proma 150 and will work perfectly with the G200 Gcode command just like the Proma.
Cheers Peter
Yes Peter your right, it's a standard Up / Down process that uses the G200 plus most of the codes following.
T112 M6
M666
G200 F800 P10.0 D800 C1.5 V31 A0 O0 S0
Cheers.
segoman-designs
SegoMan DeSigns
Perhaps it is my thinking from the PP of ver 4.01 they are the commands to turn on / off the 2 sets of solenoids needed for the air drill & air scribe. we are talking 4 total solenoids (of various configurations) and air regulators that control speed & download pressure.
I don't fully understand your setup however if one of the solenoids operates and moves the drill or the air scribe into position on the Z Axis then these simply connect to the Scribe up/down output or the appropriate spindle select for the drill.
When you select the scribe the Scribe up down output will immediately go high lowering the scribe and position..
When you select the mill tool for your drill these spindle select output will change to high. And lower the drill into position
Assuming that you have a solenoid to turn the Scribe on and off you simply connect that to the Scribe on off output and when it receives an M3 command that will turn the sky on and when you do any M5 would turn the Scribe off.\
When you select the drill you can use spindle control pin 2 to turn the drill on with an M3 Command and off with an M5 command.
If your drill has speed control then you can use the spindle speed control functionality to control its speed. That could be vfd step-and Direction or PWM signaling depending on what your drill requires.
I don't know what other solenoids you might be using and you would need to elaborate on those.
Cheers Peter
When you select the scribe the Scribe up down output will immediately go high lowering the scribe and position..
When you select the mill tool for your drill these spindle select output will change to high. And lower the drill into position
Assuming that you have a solenoid to turn the Scribe on and off you simply connect that to the Scribe on off output and when it receives an M3 command that will turn the sky on and when you do any M5 would turn the Scribe off.\
When you select the drill you can use spindle control pin 2 to turn the drill on with an M3 Command and off with an M5 command.
If your drill has speed control then you can use the spindle speed control functionality to control its speed. That could be vfd step-and Direction or PWM signaling depending on what your drill requires.
I don't know what other solenoids you might be using and you would need to elaborate on those.
Cheers Peter
breezy
Moderator
Peter suggested the following for setting up your air drill & scribe,
But you need to assign air drill to T101, one of the multi spindles, when T101 is selected the assigned multi spindle output will go high, operate solenoid and lower air drill. Then you can use either spindle output pin 2 or pins 4/5 to turn ON/OFF drill.
Multi Spindle 1 - 4
Spindle Control
Scribe Tool
As I was writing up this post Peter posted his reply.
fablab
Fablab
**A Few Months With LinuxCNC / QtPlasmaC — Follow-Up**
A few months ago I started this thread about testing LinuxCNC / QtPlasmaC on my MASSO plasma table. Now that I have cut roughly a few dozen actual parts and spent quite a few hours setting it up, troubleshooting it, and just playing with it, I thought I would post a follow-up.
To be clear I am not posting this to "bash" MASSO in any way, If anything I am posting it in the hopes that it will help MASSO improve!
I still am a big fan of the MASSO & would highly recommend it to most people.
To be clear, I run 2 MASSO production machines at work, 1 custom built plasma machine, and 1 retrofit plasma table. There are no plans to change them.
LinuxCNC / QtPlasmaC can definitely be challenging to get set up and dialed in. There are a lot of settings, and it gives you plenty of opportunities to configure something incorrectly. However, once I worked with it for a while, I realized that it is very predictable. It may not seem that way at first, but when something does not work, there is normally a logical reason for it. Once you understand the signals, settings, and how the different pieces interact, the behavior makes sense.
The plasma-specific features have lived up to my initial impression. Material handling, probing, THC operation and visibility, cut recovery, scribing, hole handling, and the amount of information available to the operator are all very good. More importantly, if I do not like how something works, I can usually find where it is controlled and change it.
For perspective, I have now used GRBL, ChiliPeppr/TinyG, Mach3, Mach4, MASSO, Langmuir Systems’ MR-1 Cut Control, and LinuxCNC. If I build another CNC machine, I am now almost positive it will be a LinuxCNC machine.
That does not mean I have changed my opinion that MASSO is a very good controller. In fact, I would still put MASSO a close second (if not an even run). If someone does not want or need customization, follows the documentation, and stays within the intended configuration, MASSO is an incredibly solid, easy-to-set-up, and reliable controller.
Where the difference becomes apparent is when you start adding (or needing) something outside that intended configuration. My Inova AVHC setup is one example. That exposed a few bugs or limitations, and with a closed controller there is only so much the user can do about them. You either find a workaround or wait for a firmware change—“no mods for you.”
With LinuxCNC, the additional complexity is the price you pay for being able to get underneath everything. You can see what is happening, change the logic, integrate unusual hardware, and make the machine behave the way you want it to behave. That takes more effort at the beginning, but there is a much higher ceiling.
My simplified conclusion after a few months is this:
MASSO is easier until you need something it does not support.
LinuxCNC is harder until you understand it—then very little is off-limits.
I still like MASSO, and I still understand why its appliance-like design is exactly what many people want. But, after spending real time with QtPlasmaC, I now understand why LinuxCNC users are willing to put in the effort. For me, it has been worth it.
Please understand the goal of this post is that the folks at MASSO will take a look at LinuxCNC or more specifically QtPlasmaC and try to incorporate some of its features, so please don't hate me
A few months ago I started this thread about testing LinuxCNC / QtPlasmaC on my MASSO plasma table. Now that I have cut roughly a few dozen actual parts and spent quite a few hours setting it up, troubleshooting it, and just playing with it, I thought I would post a follow-up.
To be clear I am not posting this to "bash" MASSO in any way, If anything I am posting it in the hopes that it will help MASSO improve!
I still am a big fan of the MASSO & would highly recommend it to most people.
To be clear, I run 2 MASSO production machines at work, 1 custom built plasma machine, and 1 retrofit plasma table. There are no plans to change them.
LinuxCNC / QtPlasmaC can definitely be challenging to get set up and dialed in. There are a lot of settings, and it gives you plenty of opportunities to configure something incorrectly. However, once I worked with it for a while, I realized that it is very predictable. It may not seem that way at first, but when something does not work, there is normally a logical reason for it. Once you understand the signals, settings, and how the different pieces interact, the behavior makes sense.
The plasma-specific features have lived up to my initial impression. Material handling, probing, THC operation and visibility, cut recovery, scribing, hole handling, and the amount of information available to the operator are all very good. More importantly, if I do not like how something works, I can usually find where it is controlled and change it.
For perspective, I have now used GRBL, ChiliPeppr/TinyG, Mach3, Mach4, MASSO, Langmuir Systems’ MR-1 Cut Control, and LinuxCNC. If I build another CNC machine, I am now almost positive it will be a LinuxCNC machine.
That does not mean I have changed my opinion that MASSO is a very good controller. In fact, I would still put MASSO a close second (if not an even run). If someone does not want or need customization, follows the documentation, and stays within the intended configuration, MASSO is an incredibly solid, easy-to-set-up, and reliable controller.
Where the difference becomes apparent is when you start adding (or needing) something outside that intended configuration. My Inova AVHC setup is one example. That exposed a few bugs or limitations, and with a closed controller there is only so much the user can do about them. You either find a workaround or wait for a firmware change—“no mods for you.”
With LinuxCNC, the additional complexity is the price you pay for being able to get underneath everything. You can see what is happening, change the logic, integrate unusual hardware, and make the machine behave the way you want it to behave. That takes more effort at the beginning, but there is a much higher ceiling.
My simplified conclusion after a few months is this:
MASSO is easier until you need something it does not support.
LinuxCNC is harder until you understand it—then very little is off-limits.
I still like MASSO, and I still understand why its appliance-like design is exactly what many people want. But, after spending real time with QtPlasmaC, I now understand why LinuxCNC users are willing to put in the effort. For me, it has been worth it.
Please understand the goal of this post is that the folks at MASSO will take a look at LinuxCNC or more specifically QtPlasmaC and try to incorporate some of its features, so please don't hate me
breezy
Moderator
Know nothing about QtPlasmaC, but from your comments I take it you can write scripts to handle virtually any problem that may arise.
Would, when MASSO's Lua scripting is fully implemented be able to do the same thing?
fablab
Fablab
I should have been clearer with that statement. My point was not that QtPlasmaC lets me write a script to fix virtually any problem. I am reasonably comfortable with scripting, but that is not really what solves my biggest issues with MASSO’s plasma operation.
Lua scripting may eventually make it possible to work around some problems, but that depends entirely on what MASSO exposes to Lua. A script cannot change the restart behavior, motion planner, or Arc OK sequence unless MASSO provides access to those functions. Personally, I would rather see the basic plasma behavior handled correctly by the controller than require users to write scripts around it.
My biggest issue with MASSO plasma is cut recovery.
With QtPlasmaC, I can press Reverse and the machine backs up along the actual path it just cut. I stop it wherever I want, then press Cycle Start. QtPlasmaC performs the same normal plasma-start sequence it would use at the beginning of the program, including waiting for Arc OK before beginning forward motion.
With MASSO, recovering a cut can require backing up a very long distance.
If I use Jump to Line instead of Plasma Restart, MASSO backs up to the previous M3 rather than simply beginning at the line I selected. If I use Plasma Restart, as far as I can tell, it still backs up to the previous corner or G01/G02/G03 transition.
That can be a substantial distance. At work I regularly cut parts from 72" × 144" sheets. If the previous corner or motion change is at the other end of a long cut, MASSO may need to retrace most of that distance before it reaches the restart location.
Plasma Restart also appears to assume that the arc starts immediately when the torch command is issued. In the real world, there is preflow time, arc-strike time, and sometimes other delays. It is similar to allowing for spindle spin-up time on a mill. With a flying restart, the machine can be well past the desired restart point by the time the arc actually transfers.
This becomes especially difficult with the square-to-round ductwork I cut. The round end may consist of a large number of short line segments. It is difficult to determine exactly which line should be selected, and even if I find it, the flying restart may carry the torch past that point before the arc is established.
G-code navigation makes that more difficult than it needs to be. I cannot scroll through the G-code one line at a time on the F2 screen. If I go to the F6 screen and use Edit, I still have to move through it a page at a time. The last line I was looking at becomes the first line that disappears from the screen, so it is very easy to lose my place.
My other major issue is the fixed timeout between M3 and receiving Arc OK, which I believe is approximately five seconds.
On my machine that time can include probing, preflow, arc establishment, and the sequence controlled by the external Inova AVHC. That fixed timeout has effectively prevented me from cutting 1"-thick material because MASSO times out before it receives Arc OK.
At a minimum, I need that timeout to be user-adjustable. Ideally, it could be configured by tool or material because thin sheet and 1" plate obviously do not have the same start sequence.
My current workaround is to disable Arc OK in MASSO, use approximately a 1.5" lead-in, and turn the feed-rate override down as far as it will go. I listen for the plasma to pierce completely, then press Feed Rate Reset. It works, but it is not a very good solution, and it defeats the purpose of having an Arc OK signal.
Could Lua scripting eventually help with some of this? Possibly, if MASSO exposes enough of the motion, G-code, torch, and Arc OK state to Lua. However, simply adding Lua does not automatically make it possible. Reverse run along the active toolpath, restarting with the normal plasma sequence, waiting properly for Arc OK, and allowing the Arc OK timeout to be changed are really controller-level plasma features.
Those are the kinds of features I would like the folks at MASSO to examine in QtPlasmaC. I am not asking MASSO to become LinuxCNC, and I do not think users should need to become programmers to operate a plasma table. I would like MASSO to retain its simplicity while incorporating some of the plasma-specific behavior that QtPlasmaC already handles very well.
And just to make sure I am clear, the last thing I want is to come across as though I am upset with MASSO. It is a very solid platform, but after using the plasma side in a real production environment, these are the issues I encounter on a day-to-day basis.
breezy
Moderator
Point taken.
The rest of your current post clearly spells out what MASSO needs to look at in regards to normal plasma operation.
segoman-designs
SegoMan DeSigns
What do we need to do to make sure this happens? This topic has been discussed on many of occasions yet it gets kicked down the proverbial road with little attention from MASSO. After reading all of this thread it makes me hesitant to upgrade as it still has problems associated with restart. Once the upgrade process takes place I have 1,000's of cut files that become useless.
@segoman-designs
The files never become useless.
Every file is a learning curve, those new into it will never understand.
@fablab, My biggest issue with MASSO plasma is cut recovery.
Have you worked out why you would require cut recovery on duct work.
For over 27 years I would have only had to restart maybe 7 times, the cuts were over 4.2 meters in length.
Sometimes a simple switch can help with the restart process.
If you are having the problems you specify, go back to the source, it maybe related to your equipment.
I don't believe there is anything wrong or can't be worked out in the Masso G3, it's up to the individual to solve their own problems.
Works fine for my situation.
Cheers.
The files never become useless.
Every file is a learning curve, those new into it will never understand.
@fablab, My biggest issue with MASSO plasma is cut recovery.
Have you worked out why you would require cut recovery on duct work.
For over 27 years I would have only had to restart maybe 7 times, the cuts were over 4.2 meters in length.
Sometimes a simple switch can help with the restart process.
If you are having the problems you specify, go back to the source, it maybe related to your equipment.
I don't believe there is anything wrong or can't be worked out in the Masso G3, it's up to the individual to solve their own problems.
Works fine for my situation.
Cheers.
segoman-designs
SegoMan DeSigns
Dingo,
Without the G200 and tool selection commands on the older files they will no longer be a useful cut file. The Time it would take to upgrade the original files for cutting on the latest firmware, one could take the original art files and run them through the new PP much quicker.
Without the G200 and tool selection commands on the older files they will no longer be a useful cut file. The Time it would take to upgrade the original files for cutting on the latest firmware, one could take the original art files and run them through the new PP much quicker.
Yes, you are right, but once done it works fine.
I've had to change all files when used again.
Cheers.
It would take less than 30 seconds to put MASSO into Legacy mode.
- Open the MDI screen.
- Type G200 and press the Run button.
- Close MDI, load your old files, and run them.
Personally I would open the file in the MASSO editor or on my PC when I put them on the flash drive. At the very top of the file I would add a line that says G200 and save the file.
This way the G200 command that puts MASSO into legacy mode will always be present in the file whenever you choose to run it and you don't need to remember to do it in MDI when you start the machine. With G200 at the top of the file, you will be able to immediately see whether or not the file has a G200 added to it for legacy mode.
No matter what method you choose, it isn't difficult to run a legacy file in the current MASSO software versions.
Cheers Peter
fablab
Fablab
I want to clarify that I am not saying MASSO is causing every situation where I need cut recovery. A plasma cut can stop because of a consumable problem, failed pierce, loss of arc, material movement, collision, air issue, power-source issue, operator feed hold, or several other things that have nothing to do with the controller.
The controller’s job is to provide a practical way to recover when one of those things happens.
As for only needing to restart approximately seven times in 27 years, that works out to 0.259 restarts per year—or one restart every 3.86 years. Assuming 250 working days per year, that would be approximately one interrupted cut every 964 production days.
I don’t doubt that is your recollection, but that number is so far outside my experience with production plasma cutting that I have to assume we are defining or counting a “restart” differently. Perhaps you are only counting particularly memorable failures on very long cuts, or perhaps situations handled with a manual switch or another workaround are not being included as cut recovery.
At work, I regularly cut 72" × 144" sheets. One sheet may contain square-to-round ductwork made up of a large number of short line segments, while the next may have more than 100 individual parts nested on it. Tip-ups happen, consumables fail, and cuts occasionally get interrupted even when the equipment is working properly. Scrapping the affected part or restarting a large portion of the program is not always a reasonable solution. That is exactly when an effective cut-recovery feature matters.
A simple switch may help manually fire the torch, but it does not make MASSO reverse along the actual programmed path, allow me to stop at the desired location, perform the normal probing and pierce sequence, wait for Arc OK, and then continue forward. Those are the specific behaviors I am discussing.
MASSO already includes a feature called Plasma Restart, so clearly MASSO also recognizes that interrupted plasma cuts occasionally need to be recovered. I am not criticizing MASSO because a cut sometimes stops; I am providing feedback about how its recovery feature behaves when that happens.
If Plasma Restart works well for your equipment and the type of work you do, that is great. It does not work particularly well for my production environment, for the reasons I have explained. Different machines and different work can expose different limitations.
Ultimately, the frequency with which a recovery feature is needed does not determine whether it should work well. I may go years without using a fire extinguisher, but that does not make a poorly functioning fire extinguisher acceptable when I finally need it.