Advanced Search

I understand your observations. Honestly, I don't have any way of knowing if the working drive has been repaired before, but it's a definite possibility, especially considering it could be up to 30 years old!
​Regarding the corrosion near connector CN7, it's hard to say for certain if it's due to a cold solder joint or other factors. Furthermore, the pasty substance on the transistors above could indeed be solder flux (residue from the assembly process or a previous repair), or it could be liquid leakage from the nearby electrolytic capacitors, which would indicate another potential issue. Both hypotheses are plausible on electronic boards of that age.

Finding all necessary inputs for systemstate estop in those linux systemfiles on github is above my paygrade. What could trigger estop internally?
iocontrol.user-enable-out has to be TRUE aswell for estop reset to work? 

I’ll have to peak in and look at how many sensors it has, everything I’ve seen it looks nearly identical. I’m in the states, in Texas.

This is my second linuxcnc machine I am in the process of building (First one was a C axis lathe). This is a very simple 3 axis mill and I am running into some sort of issue with the limit switches that I cannot for the life of my figure out.

Here are the facts

1. Wiring is all the same as my first machine, using a mesa 7i96s (same as prev machine as well)
2. I set my input 0 as my X min limit (although have tried home/min, max, home/max) have also tried inverted and non-inverted
3. When I get to my X motor test/tune page, I go to my halmeter and I PROBE GPIO-000 AND input-00 BOTH of them correctly change states when I press the limit switch, indicating it seems to be working correctly.
4. HOWEVER, when I open the actual machine program (am using gmocappy) the limit switch no longer works / does not change state - neither gpio-000 nor input-00 change state. If it is inverted in pncconf it will show the switch as always active and thus I cant turn on the machine, and if it is non-inverted, the limit switch simply does nothing.

I am utterly confused, it is the same code as the other machine, I must be doing something stupid but I am not seeing what that is. I will upload my hal/ini, can someone please help? Like I said I have tried setting it as all sorts of limits and homing and whatnot, and have tried inverted / non-inverted.

I am so so confused....


edit: just as an FYI - the actual axis motors move correctly, so I don't think its something like the mesa is not being communicated with in the real instance of the software
edit2: could it have something to do with the fact that i am using the same computer for both machines? (I unplug one mesa board and plug in the other when i want to run the 2nd machine)
 

i left the pin asignments as they were, just changed the dropdown to change it from normal Y axes, and Tandem.

i.e.
Pin 4 and 5 set as Y-Step and Y-DIR
Pin 8 and 9 set as Tandem Y-Step and Tandem Y-DIR
This causes the left motor to move when testing, right motor does nothing

Pin 4 and 5 set as Tandem Y-Step and Tandem Y-DIR
Pin 8 and 9 set as Y-Step and Y-DIR
This causes right motor to move, left motor does nothing

I didn't swap any of the physical signals, just that one setting in the stepper config wizard.

If i set the machine to XYZA, and set both motors are normal, making pins 8/9 the A axis. i can jog both motors individually in the wizard's test feature.

If i swap which is Y normal, and which is Y tandem, the other motor moves, and the original motor does not.

This is not really clear, dd you swap the hardware or the Y and Y2 functions in the hal file?

(that is, did you verify that the parallel output pins 8 and 9 work as expected)

 
 

Upload hal and ini files here so we can have a look.

Yes. It is a parallel BOB.
In stepper configuration wizard, i set Y as normal axis, and the secondary motor as Y tandem. (read that somewhere here in the forums)
Both sides have their own limit switches.

Testing in the configuration wizard:
Setting Y axis as normal, and the additional motor as Y tandem.
Then going forward to "test" only 1 motor moves.
If i swap which is Y normal, and which is Y tandem, the other motor moves, and the original motor does not.

Deciding to go ahead and finish the configuration wizard, and test it in linuxcnc, the same issue occurs. It attempts to home only one motor
This is the issue i've been trying to find a solution to.

Hmm. That's unfortunate.

They talk about getting the machine in the proper state to rerun the tool, I assume with all the proper G codes in operation (G17 etc.)

Most of the machines I ran back when I was a machinist by trade remembered those unless a M30 was called. Unless you started from a different tool, the same state was still in effect and the machine just started from the line called.

If you called a different tool, you might need to do some wizardry to get the machine back in the proper state.

Anyway. Looks like I am not the only one with this issue.

Thanks for the help.

Since you failed to mention, i am assuming this is a parallel port setup, so is it?
I think the 2.10 version of LinuxCNC will have tandem axis in wizard for parallel port, for Mesa there is already any combination possible in the wizard.
There is no howto as it is very simple, open wizard, choose axis and what axis is tandem, some math with motor/pulley/final drive/, and save, test.
Also, it seems you came form Mach3 side of things as there is no slave in LinuxCNC, there is tandem joints and can be more than two fro the same axis.
And using LLM for this is still just plain useless, and so is google, next time try duckduckgo.com it still seems to find stuff that is fully hidden to google.
Finally, a qustion before you wander again to the deep end of the pool:
Do both sides of Y have their own home switches?
That is a must to be able to square the gantry any time the machine is homed.
But, if you do not need gantry squaring, you can:
-wire both motors to the same drive, in series as the cable length is not an issue, or in parallel but both cable sets must be the same length
-wire both drive inputs to the same PC output, be it parallel or Mesa or Pico or Remora or Rio
-set in software/HAL to output of Y axis to both drives, simply by choosing Axis Y twice in the wizard.
All of these do not require any home switch, and can not do gantry squaring. But they do work with switches.

aaeon (asus) has a dual nic pico itx motherboard with a celeron n150 that I have been looking at for linuxcnc/ethercat. It is I think $248 (plus ram and m.2 ssd). it also takes 12v power via terminal blocks so it seems like a good option at least on paper.

Hi team, good day, I need some help, I have a Mdx-500 roland, but it's no runing, it's stock in a when turning on it, I dont konw why

While i'm no stranger to linux, i have to admit, trying to get my machine up and running in LinuxCNC is the equivalent of throwing a toddler into the deep end of the pool, and expecting them to win a 500m butterfly race. I need help with this. because my experience with LinuxCNC thus far, just makes me want to wipe the hard drive, and find literally anything else. 

There's just NO documentation on how to do it. There are small hints here and there, and a plethora of forum posts that tackle small bits of this or that, but not a single unified, digestible "this is what you have to do" type of guide. I've spent the better part of a week, crawling google, bing, facebook ,the forums, the documentation, the github, and it's just EVERYWHERE. Most of it, is seriously old, and outdated information. 

At the end of the day, i just feel swamped with a mountain of unusable information, configuration files, and a plethora of "almost there" configuration wizards, and i've made absolutely zero progress. 

Yes, this may seem like a rant, and honestly, it kind of is. Something as simple as slaving one motor to another shouldn't be this convoluted. A simple drop down and checkbox in the wizard should have been all that was needed to slave A to Y. 

// END RANT //

All i need, is a step by step proceedure for slaving my A drive to my Y drive. 

 

Thanks for the github link. I will look into it in detail.

Currently everything is doing what it´s supposed to do, signal wise.
When i disable the estop relais (hardware wise) i can see a reset pulse as described in the hal excerpt above, using halscope.
halui.estop.is-activated just stays in estop.
If i set F1 in gmoccapy, the GUI puts out a warning about external estops being set. I have literally no idea what net could be the reason for that behaviour.