Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: c30232 on February 12, 2014, 03:53:19 AM
-
4' X 8' 3 axis gantry with 4 motors. Y and A are slaved
I have advanced from jogging and homing to running an 8" x 8" carving that took about 4 1/2 hours of run time. Life was good and I thought it was time to run the router problem free. However, during a table surfacing operation I experienced a crash or runaway machine. The operation is thus:
Z is constant at table level
Y moves positive the diameter of the cutter and holds
X moves the width of the table.
Y is a two motor gantry slaved with A counter rotating
During the operation X stopped its travel and Y attempted to move without command, however, A is reversed. The event occurred three times with varied movements of X and Z, but all included the similar Y movement and resulting gantry torquing.
Any ideas where the destructive commands are coming from?
-
Attach your xml and I will have a look at your config, also what version of Mach are you using so I can simulate with it.
Hood
-
Thanks,
I believe the only thing messed with after the carving was the soft limits and CV mode. We had problems with the limits as you will see they are not set.
-
Version R3.043.066 I believe this is correct. I will check the machine later.
-
xml looks fine, assuming you are not on the edge with your motor tuning.
So next question, when things went haywire, did the DROs in Mach correspond to the weird positions r were they where it should have been?
Also did you hear unusual noises from the motors?
Hood
-
The machine is wired in temporary rats nest format thus the scramble to shut it down is distracting. Because of the racking of the gantry, it's not something to replicate and document.
Mach may be running as though nothing went wrong. I am confident this is the case, but I will make better note if it occurs again.
There are three power downs
1) Power to the driver which is the first to hit.
2) Mach
3) The power to the BOB
Mach may be running okay and has no effect during a screen e-stop.
When the power is restored to the drivers, the crash heats up again with Mach in Reset/E-Stop
A power down of the BOB releases control and the drivers can be re-powered and Mach is good to go.
It is to hard to hear over the other equipment, however, nothing seems off with the steppers. Remember Y is at rest when this occurs. It seems that A gets a go signal and because of racking it is not so far not possible to determine if Y is running also. The last crash was in the opposite direction of the others.
There are indicator lights on the BOB. I do not speak their language, however, there are 4 red lights that seem to indicate a direction . . . perhaps they are modal. Thus when Y is in motion only on of the two axis, Y/A, lights is on. One light for this direction and the other light for that direction . . . never both. After/during the crash both A and Y are on.
-
The machine must be homed after the crash further supporting the Mach is doing its thing. Here is a link to the BOB. I have been unable to acquire documentation . . . I am in contact with Campbell but still no docs. I bought the BOB new . . . go figure.
http://campbelldesigns.net/Combo-board.php
-
Rats nest is not good when using low voltage signals :( That could well be one of the issues as its easy for noise to get into the wires and affect things.
I think the motor tuning parameters for a slaved axis is irrelevant but I am not 100% sure so make sure the A is set to same steps per unit and Velocity/accel as the Y.
Even if the motor parameters dont matter I would think it is possible to change the active state of the Dir pin on a slaved axis to make it go the opposite way, if that is the case then the Dir LEDs may be correct with one off and one on as it will depend how you have the motors wired and also whether the motors are at the same end or opposite.
If Mach is indeed showing the position correctly when the axes go wild then I would say it is most likely noise or loose connections that are your problem.
Hood
-
Well . . . it is an orderly nest and certainly not as constrained or twisted as when confined to its enclosure. Please give it some more thought. It is at rest and seemingly the BOB get a ghost signal to go crazy. The BOB is isolated . . . I think. If it is noise, why didn't show during the multi hour carving run? The time for that run was actually 4 1/2 hours.
I could believe a poor connection. I pound my trusty assistant not to Gorilla-hand stuff and I get loose instead. What connection would set that condition? I though it could be a short triggered by position, but that seems to be ruled out. Hmm, I was focused on Y. The X was near the same location during all crashes . . . about mid travel. The motor wires are shielded, but the terminations are not. Could a short do the job? If yes, how does it reset itself?
I will check the mechanical connections and give it a go.
When A is slaved, all else seems null as far as Mach . . . I think. I will set them mirrored to be sure. The direction lights are proper because a slaved movement has to different directions of rotation.
Thanks!!!
-
Thought that was the way it was with slaved but been so long since I did have a slave set up (was on the coil winder) that I couldnt be sure.
Regarding shields, they need to be grounded or could potentially cause more issues than without, presume that is what you mean by not terminated.
Step/Dir wires should ideally be shielded, in fact all low voltage signalling should be.
The slaved motors rotation direction will depend how you are set up, sounds like you must have one screw with two motors either end but anyway doesnt matter, if its the correct way for your setup then the LEDs on the BOB should always be the same. Noise however could easily get in and change them.
So the thing you need to find out is if Mach shows correctly when axis are weird, if it does then its almost certainly external issues.
Hood
-
The machine is wired as from the manufacturer. I assume the shield is to ground or a the machine. The terminations of the conductors are not shielded. I assume that the machine worked at some point in history as it shows that it actually touched some material. Mach and the are new to the system and the drivers are new OEM.
I will try the following when the shop closes:
Without any change run the 4 1/2 hour carving, if no crash then>
Run the table surface with no changes, then crash or no crash>
Check all obvious connections and strap the machine to a ground rod.
The ground rod is in place as a manufacturers demand to solve issues with another machine. It didn't make any difference, but we have a ground rod that reaches the center of earth.
-
The machine last crashed at about X 45" and 50"
The machine machine position of at approximately X0 and Y0
The DROs are approximately X0 and Y 2.500
Its approximate because I jogged back to the crash site after the attempt to jog home failed. X and Y are up against the soft limits. The Y DRO is off by 45" and Y could be off or correct because the operation was a restart with a new Y zero. However, get this, the skid mark is 2 1/2 inches long. Remember at the crash X stops and Y/A takes a hike.
I don't recall what Mach was doing during this crash. On the other I am now biased by the physical evidence and no longer positive Mach was running properly. I believe on the first one the the G-Code advanced as it should after the crash.
Life was good. The only thing that was changed prior to the crash was soft limits and CV. We had change CV several times with no issue. The soft limits created unexpected results. That is they were set way over there and the machine would hard stop clear over here. We did not dwell much on it and set them as they are now.
-
I am not sure what you are saying. Are you saying the axis take off and Machs DROs show the position they are at when they take off? Or are you saying the DROs show where they should be?
Hood
-
When I went to the machine I did not pay any attention to the DRO when I attempted to jog towards home before starting the homing process. In jog the DROs read as described above 0 and 2 1/2 inches. I was immediately on the soft limits. That makes the limits off by about 48 inches. Somebody could have zeroed the DROs after the crash.
However, the machine coordinates are off by about the same distance. The machine can't be zeroed in the field or at least nobody around the machine has knowledge or opportunity to make that change. It appears that the machine coordinates set to zero at or about the same location of the crash. That could explain why the machine stops on X as it believes it is at the limit. That would also explain why machine Z is off. Machine Z is off by 1 1/2 inches. That means machine Z sets to something other than zero.
-
Hood,
A heartfelt thanks from across the Pond. It is a pleasure chatting with someone who gets it. You may have forgotten that you helped resolve some issues with our plasma table early last year. Your observations were spot-on.
I am hoping your suggestion of noise is the answer. I dry ran the table surface code from the last crash forward without a hitch, that is, one hour or double the time between crashes. I will run it again time permitting.
Absent in the run are the following:
1) Table Vacuum
2) Router motor and its VFD
3) Shop vac dust extraction.
Remember that we ran 4 1/2 hours while carving without a hitch. The only wild card is the shop vac. The shop vac was introduced for the table/spoiler operation. Do you think static from the vac tube/hose could cause the crash?
-
I am no expert in noise, in fact I dont think anyone can really claim to have all the answers regarding it as there are just so many variables and what seems to work on one machine may make things worse on another. Industrial machines have for years used much higher signal voltages (24v) for normal I/O and differential signalling for smaller voltage signals (encoders, step/dri etc). That is the best approach but obviously it is not the easiest to implement on a system that is already built and set up.
The common sources of noise are VFD and Spindles, and other motors such as vacuum etc, finding which if any is the problem will just be a case of trying to run without and then introducing one at a time.
Hood
-
Thanks again
I set out to run the machine again today and discovered the machine coordinates are reading zero. That is 2.5, 45, and 6 inches from the home switches/machine zero. I homed X and sent Y home. I stopped Y to do another task. I then sent Y home and Mach went to E-Stop because of soft limits. When I mouse click the Mach reset the Y DRO changes with each click of the reset. The machine Y coordinate changes the same amount at .001" per click. The software for whatever reason is resting the machine zero. Any idea why. Improper setting or a bug?
-
Can you zip and attach the screenset you are using please, it has to be the one from that machine as it may be different from others.
Hood
-
I believe this is it.
-
This probably has nothing to do with the problem but I would not use ver 0.066 it has problems. I was running it and experienced strange intermittent issues. I loaded 0.062 and the problems disappeared. If you are using a cheap chinese VFD... they are very noisy in the RF range especially with the carrier frequency set in the lower range.
-
It seems 066 is the current version. Where do I find 0.062?
I considered the lower setting, but have not yet tested for that. It is indeed a Chinese VFD and it is set in a lower range. It was set at full tilt when I ran the 4 1/2 hour no crash run.
However, as the problem exists right know, I reckon the VFD has nothing to do with it as the power to the VFD has been has completely disconnected. It occurred to me today that the PC and Mach we are using is from another table that, as far as Mach goes, was running impressively well. In its new assignment there are two changes that would certainly relate to Mach:
1) A single circuit home switch setup was added.
2) Setting of soft limits.
When the soft limits were set we began to have problems. The machine would soft limit out when it was a mile away from the setting, We didn't mess with it and set them as they are now. That is, well off the table.
-
Sounds like a conflict with the new home switch and/or soft limits.
1) Are the native units (mm or inches) set correctly.
2) Are the soft limits correct for the table size and movement direction?
It almost appears as though the machine home location isn't correct to the table size. What happens when the "Ref Home" command is issued?
-
The machine is factory wired with three proximity switches on a single circuit. The soft limits are currently set larger than the actual table. Upon the home command the following occurs:
1) Z homes up
2) X homes left or negative to zero
3) Y homes forward or negative to zero
The machine actually makes the move and visually returns to the same spot each time. I have not gauged that landing. However, out and back on several consecutive 98" Y movements the return lands + - .001". Thus it seems to count correctly.
Zero,zero is the left forward corner. X is 48" and Y is 98". The native units are set to inches and the g-code is generated by a Mach wizard. The code is an easy read and there are no surprises in the crash position.
What would reset machine zero mid table?
Mach is set to auto zero. The xml is posted in a previous thread.
-
The major change was adding the home prox switch. Can you disable the prox switch... only using the soft limits and see if the problem is still present? Prox switches use a solid state device to either sink or source the output logic. The wrong type of prox (NPN or PNP) wired to a BOB can cause strange problems.
Generally the X direction is the longer and Y is shorter. Yours are reversed which isn't a problem if Mach is set up for that.
-
The home was in place, I believe, before the 4 1/2 hour run. However, I agree that the sprite of the issue resides somewhere in the home protocol. It will be very easy to disconnect it and just as easy to live without. I wondered about the NPN v PNP when we hooked it up. It is something I don't have a good understanding of and the fact that it worked caused me to believe we got lucky. I can't locate a diagram for the BOB and it is somewhat trial and error.
X is simply left to right and matches other stuff, some longer, some shorter.
I will take another stab at it in a few minutes.
-
It seems 066 is the current version. Where do I find 0.062?
You can get previous versions from the ftp site.
ftp://machsupport.com/Mach/
Russ
-
Typical 8 & 12mm barrel type prox switches are normally open (NPN or voltage sinking) and can't be wired in series with other prox switches. This is a common mistake people make thinking there is a internal switch contact. Each switch has to have a separate input assigned in the BOB and Mach 3 configured as required.
The draw back with a NPN prox switch is there is no broken wire safety aspect. So if the switch fails or a wire falls off a terminal will result in a axis homing crash. Normally closed prox switches (PNP or voltage sourcing) are less common and usually much more expensive.
-
Thanks,
You have correctly identified the switch. I will disconnect them without making any other corrections and pretend it is the source of the problem. We shall see.
The BOB is capable of individual home runs. I agree it will be better but it will require a rewire of the machine. I guess that will force us to examine the other wiring . . . not a bad idea.
The mystery to me is that the machine did run with all of its bad habits . . . maybe. The person I got it from never saw it run. Perhaps that is why it was for sale. But, it is apparent that it did do some work in its day. It's not beat, but it has some dirt under the fingernails.
-
Geh,
We just completed a dry run with no issue. It's now running the cycle with the router on but not in the cut. While running, I tripped the proximity switches one by one and there was no response from the BOB or Mach.
-
I'm glad its been narrowed down.
I assume the prox switches are incorrectly wired in series which is why you didn't see a response from Mach or the BOB. Almost all prox switch have a LED indicator light mounted someplace on them, usually where the cable is attached, which is a great troubleshoot tool to test the function. Prox switches require 12-30 vdc supply voltage. Below 12 volts or over 30 volts can result in unpredictable or failure to operate.
While its possible to configure Mach... I've never been a fan of series wire mech limit switches unless the BOB doesn't have the inputs.
-
Sorry been hectic and not had a chance to get to the forum the last day or so. I looked at your screenset and tested with your xml but could not see anything wrong and could not get the reset to step the Y DRO as you mentioned.
Looks like you may be making progress though :)
Oh did se some weird settings for your Jog buttons, but likely you have a reason for that?
Hood
-
Pray tell, what jog settings? If they are in the xml they are set by the BOB folks. I did today check some of the stuff you mentioned. Every BOB termination was loose. Not sure what that would do, but in a water pipe it would drip from time to time.
-
Is there a software fix for an out of square gantry?
-
Usually you have two home switches for the gantry, one on main and the other on the slaved side. When you home then the gantry will be squared to the switches.
Hood
-
It seems out farther than that. Just messing with the spoil board and framing square it shows out of square in the same direct each time. I have applied pressure in the direction of correction but that causes the otherwise smooth gantry to rumble. I need to do some measuring, but it could be out as much as 1/8 inch overall. I hoped there could be a software compensation. A mechanical adjustment is not obvious. I guess having no manual is the bitterness that results from buying cheap stuff.