Advanced Search

I'm sorry, I missed it

jjdege wrote:

Sorry, there are no pins connected to the Mesa IOs.

Yes there is a pin, it is way up in his hal file

Sorry, there are no pins connected to the Mesa IOs.

I've got my machine setup to use a rotary table as the W axis since I already have a C axis on the head.  I've added wrapped_rotary=1 to my ini in both the joint and axis sections, but it's not working.  Does wrapped rotary only work on A,B, or C axis?

I also have the rotary table setup as a second axis and what I would like to ultimately do is setup the rotary table to wrap the axis position at 360 and also keep track of the position while using it as a spindle.  Right now I just use a generic mux2 to switch the joint velocity between W axis velocity and spindle 1 velocity signals using the spindle.1.on and it works great, but I'm not sure how to keep the axis position when it's in spindle mode.  I'm using step/dir servos to drive the table, so I don't have an encoder on the table output itself.  Is there a way to fake an encoder signal from the spindle output to feedback into the joint position?  

lcec_conf:

You should most probably save the config then run it, then home the machine as jogging will not work for tandem axis before homing.

At a quick glance, normally you would need to connect the joints to the cia402 components, see here github.com/dbraun1981/hal-cia402/blob/main/example/cia402.hal 
In this case you can try to give a position value to cia402.0.pos-cmd


 

I am trying to get Leadshine 2CS3E-D507 working to drive two closed-loop steppers to drive the carousel and arm of a toolchanger in simple pp mode.
I think I am very close, but need some help to get over the line.

Scott Laird's driver and the Cia402 component have gotten me to the point where the drive reaches OP state and I can see all the hal pins, but I have not managed to get the steppers to move.

To avoid the complexity of the rest of my machine, I have simply taken one of the sample configs (sim.axis-min), and added two extra joints (joints 3 and 4) for the two closed-loop steppers in the ini file , and added a hal file with what I hope are plausible lcec and cia402 settings. I have then connected the stepper drive to the machine with an Ethernet cable, Linuxcnc starts up OK with no complaints, and ehtercat slaves shows that the 2CS3E-D507 is sitting happily in OP state.

Looking at Machine>Show Hal configuration I can see all the lcec and cia402 pins. Setting setp cia402.0.enable 1 turns on the first joint and the same with cia.1.enable turns on the second one. I can see that this is the case because the LED display shows the corresponding dot. The display shows 88.8. where the dots denote one active axis each.

Reading the position of, say, the first stepper (lcec.0.0.srv-1-actual-position or cia402.0.drv-actual-position ) shows a value of "97", and the other one shows "2". These are arbitrary values corresponding to whatever position the shaft was turned to when powered up. 
The corresponding "target position", however, is currently "0", but the drive is not trying to turn from position 97 to 0 at all.
In fact, it seems very determined to hold its current position, so you cannot turn the shaft by hand (which you can easily do when the drive is not enabled). It seems to resist any attempt to move it from its current position of 97

Trying to write a new target position using "setp" fails.
For example, if I try to set it to 700 : 
using setp lcec.0.0.srv-1-actual-position 700, it complains that the pin is connected to a signal ( r1-drv-target-pos )
Using setp cia402.0.drv-actual-position 700, it complains " ERROR setting parameter 'cia402.0.drv-actual-position' to '700' pin 'cia402.0.drv-actual-position' is not writable"  

The relevant line is the hal file is 
net r1-drv-target-pos      cia402.0.drv-target-position => lcec.0.0.srv-1-target-position
so I can understand the first complaint (the lcec is taking its input from the signal r1-drv-target-pos, which is getting its value from the cia402.0.drv-target-position pin), but I can't understand the second complaint ( the cia402target position pin not being writable), because one has to be able to tell the drive what the new position target is

Is here a simple fix I am missing, or am I going about this completely the wrong way, and if so, what do I need to change?
Since it's for a tool changer I would like to stick to pp mode rather than csp to simplify things.

I am attaching the .ini and .hal files, which are the only modified ones. All others are as per the normal sim-axis-min sample config in the standard installation.

Many thanks!
 

This has been fixed, thanks for the report.

JT

I can duplicate that error so should be fixed shortly.

JT

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.