Advanced Search

  Hello to everybody
I use to retofit mill and lathe with linuxcnc , all of them with probe basic.
All of them are working  , i do this for hobby.
Now  i build a hot wire foam cutting machine , a large one , 3m*1,7*1,7 m ,(for 1,2*1,2 section cutting) 4 independent axis
It is configurated with 7i92+7i76 board (old type both of them , remain from other project ) , including the mechanics , remain from projects  , linuxcnc , axis - foam configuration.
On desktop looks like work.
I need an advice , a configuration , an ideea how to manage the wire change of lenght , with a stepper motor , not mechanicaly with spring , pneumatic cylinder , or weight on both sides.
Something like a 5th axis.
I tryed with double y and v axis (vertical axes) ,  mirror axes like routers , XYYUVV  , the mirror axes move and rotate a whell and 'recover' the lenght of the wire , but in my opinion is a better solution , I think with only one motor that can compensate and manage the lenght change.
Thanx in advance
Denis

I was wondering the same thing, i recall being 8 back when multiple spindles were implemented.

even though the Docs say 9

could you point out where in the docs you found that? 

Seems to be correct here:
 
linuxcnc.org/docs/html/examples/spindle.html

papagno-source wrote:

The machine with refClockSyncCycles=-1 normally doesn't emit any noise, except for some window movements.
With refClockSyncCycles=1, it emits some noise.
With both refClockSyncCycles=-1 and 1, the command
ethercat upload -p 0 -t uint16 0x1C32 0x01 returns 0x0002 2
Pin pll-error oscillates around -1200 to 1300

When moving windows Linuxcnc's servo loop takes too long time.
There usually is a message in the start window saying that.
If you monitor pll-err in halscope or record it with sampler you will
see a spike in pll-err.
There is some more fundamental work needed to make linuxcnc independent
on such events.
Wouldn't surprise me if this is the difference between 4.19 and 6.

Had another peek at the vid on a bigger screen, and each pass is certainly starting to the right of the previous pass.

Start of pass 2, chip is forming on the right of the insert:
 

Two rotations later, and you can see a second groove forming to the right of the first pass... but it isn't much deeper.
 

Third pass, and now there's a 3rd groove  - also to the right.  And also isn't much deeper.  Maybe deflection, but I didn't see the stock wobbling a ton or climbing the insert.  Almost like it isn't going any deeper each pass, just shifting to the right.
 

In addition to running a no-Q value test, it might be helpful to set up a halscope with the Z-axis position and the spindle index signal.  Try to see exactly where the Z-axis is when the index signal is triggered, and does the Z-axis then start moving immediately?

My earlier suspicion about the start point being the same may not be accurate - hard to spot 0.1mm-0.2mm shift of the insert on video.

Finally, you could put an ink pen in the tool holder and run a series of 3 to 4 G33 moves, using the pen to draw a thread.  Since "The G76 canned cycle is based on the G33 Spindle Synchronized Motion", multiple G33 passes should help you determine if the synchronization start point is exactly the same place without any other motion distractions.

Try it at different spindle speeds - but use the same speed for each set of repetitions.  If you want to test my claims about the bug, run a 4-pass test, but increase the spindle speed by 100-200rpm each pass.

If the start point is the same every time during G33 (same spindle speed) - but not during G76 - you've got a threading-specific problem.
If it's not the same, you've got a more fundamental synchronization problem... mechanical or LCNC configuration.  Or you may be encountering the bug I mentioned earlier from a different direction.

In your hal file, change:

loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[KINS]JOINTS

to:

loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[KINS]JOINTS num_dio=N


where N= the number of DIO needed (1 to 64)


man motion




 

meister wrote:

I'm trying to decide on a connection for my satellites

Ethernet or Firewire Cables, 5V or 24V ?

* RJ45 is cheaper, but could be confused with Ethernet
* FireWire uses thicker cablesCheaper
* satellite boards can be built using 5V, but 24V is practical for many sensors and limit switches
* RJ45 and 5V are compatible with Mesa-SmartSerial (except for the firmware)

Does anyone have any ideas?

I was going to ask you this very question, I would lean towards RJ45, tx with a gnd twisted pair, same with rx. Otherwise a properly shielded/grounded (at the source point only) cable over a short run, possibly with a bit of passive filtering. I think if either are kept as short runs and don't go looping around a spindle drive it should be OK. 

I think keeping the uart at 5v will save level shifting headaches, keep 24v on the machine hardware side of things. I have some PCB's turning up soon and I will try out the satellite expansions, looking forward to it

Longtime reader, first time poster.
Running a cnc lathe retrofit with 2.8.
I was using the y-axis as a drive axis for a tool turret. The y-servo motor moved the turret to the tool position and some simple digital outputs locked it down using an air cylinder. Unfortunately, the system was very "loose" and backlash problems and other repeatability issues meant that it wasn't very reliable. It was a good learning experience and I could get away with using just the 4 default input/outputs that came from a simple configuration.
I've redesigned the turret/indexing system for more effective indexing and this means that I need to unlock more inputs and outputs.
 I'm not any kind of linux programmer. I've used the forum to cobble together snippets of code to make things work and that's been enough for three mill retrofits so far and this lathe project.
I cant figure out how to expand the i/o so that the M62 -M68 codes can call the extended inputs and outputs that are available on the mesa 5i25- 7i77.
I can add and assign names to the i/0 in pncconfig. They show up in the hal file and I can see them in halshow. 
There is a section in hal that shows the only i/0 that  I can access.

#  ---digital in / out signals---

net dout-00     <=  motion.digital-out-00
net dout-01     <=  motion.digital-out-01
net dout-02     <=  motion.digital-out-02
net dout-03     <=  motion.digital-out-03
net din-00     =>  motion.digital-in-00
net din-01     =>  motion.digital-in-01
net din-02     =>  motion.digital-in-02
net din-03     =>  motion.digital-in-03


I know its probably something very basic but I'd like to expand this to include all the i/0 that I select in pncconfig.
I've been through the archives and I'm still drawing a blank. I'm getting errors regarding missing pin numbers and  i/0 max errors.
Any help would be much appreciated.

Solved. 
The problem was my KINS part of the ini. I had it the following:
[KINS]
KINEMATICS = trivkins
COORDINATES = XYYZ
kinstype=BOTH
JOINTS = 4
And they need to Look like this:
[KINS]
JOINTS = 4
KINEMATICS = trivkins coordinates=XYYZ kinstype=BOTH

Thanks for all the help.

for those that are interested

here are some forum links that helped me work out the dual feedback

plus help from Andy and others off forum

wiki.linuxcnc.org/cgi-bin/wiki.pl?Combin..._Devices_On_One_Axis

forum.linuxcnc.org/10-advanced-configura...ectory-planner-et-al

and this forum post below

forum.linuxcnc.org/49-basic-configuratio...ndex?start=10#219431

copied and pasted from the post in case it gets lost


"I don't know if you're still stuck with homing only with the switches or if you solved it closing the loop with the encoders but here's a solution I did on one of our machines (a Mazak lathe) to overcome the problem of homing with index using open loop configuration.

As Peter says, it's not possible at the moment (version 2.8) for LinuxCNC to reset the counters to zero with an index pulse if you're using an open loop configuration with steppers or servos. This is because the index pulse resets the Mesa encoder counters by hardware if I understand it right. 

But, I could find a simple way of solving this with pretty good results. Basically I bypassed the home switch on the final homing stage (when the homing uses the latch velocity) by means of detecting the joint.N.home-state of the joints on the machine. So my homing sequence is working only with home switchs, but when the time comes to do the final home switch tripping, I just use the index pulse to fool LCNC and get a more accurate homing. This is not as good as hardware counter reset, but it's working flawleslly (tested with a dial indicator). The best way to be sure the repetability is good is to use a really slow latching speed.

I hope this serves to anyone facing this problem. This shows again how HAL is amazing when it comes to adapt LCNC to basically anything.

Thanks as always to everyone!"



 

more photosThis hydraulic system really stumped me until i asked a friend (thanks Gordon if you see this)
It has a accumulator so what you do is you turn the pump on and then wait until the pressure switch triggers and turn pump off.  This machine only needs oil when toolchanging so it’s a great idea really and allows me to not need a pump running all the time.  Once I worked out how it worked it is great  and very easy to setup in classic ladder

 


next thing i need to talk about is how i am handling homing currently

this is just copied and pasted from the email user list.  great place to get fast answers to questions btw

This email address is being protected from spambots. You need JavaScript enabled to view it.


Hey guysthanks for the replies the homing is a interesting issue I had a bit of a play and made a copy of my config that i hacked.   What i found was that if i combined my original 2 PID loops into 1 loop and used the scale for position and used the motor velocity on encoder for velocity all in one PID then homing to index enable worked perfectly. but doing it that way the motor tuning was not as good.  backlash is a constant of 0.1mm and the motor just jumped across that backlash whenever it moved.  in practice that meant that the absolute scale position hovered by +-0.01 or so. this was not bad and totally usable.  If i had done this option first i would have called it good and just used it.  but the movement was much louder and less smooth than the two PID loops which get run through a sum component.  As the original two PID loops was much much smoother, it was perfect and once i come to a stop the drive rapids to within 0.01 or 0.02 and then creeps the last 0.02mm (using the integral value which takes about a second)  and ends up in the right place within 0.005mm or less.  basically perfect every time with no dithering. It is now my most accurate machine.  and really nice also the homing when homing I home all axis at the same time.  X and Y get homed to index enable like normal. and the Z value i trick the home switch by checking the joint state.  How this works is the Joint2 switch state goes form 7 when searching for switch the first time to 12 when latching on to switch slowly the second time so in classic ladder i set up two compare functions that basically choose whether to listen to the main home switch or the z axis motor encoder Z index pulse.  (this is different to the index enable pulse and this is possible to miss when only checking in software not hardware.  but at a slow speed i haven't found any issues yet, and when testing with a dial indicator i can't see any changes between homing.  I can rehome linuxcnc up the top of the travel beside the home switch and then rapid down to the table which is about 1m away and the dial indicator is definitely within 0.01 each time.  i can't really see any movement on it.

photos show the classic ladder stuff might help someone

     So pretty happy all in all would like to fix the index enable issue in the future but for now it's working fine. this is a 40 year old machine and weighs 12 ton.  and when i got it the backlash was 0.40mm.  I replaced all the thrust bearings and changed from reduction gearbox to a nice mazak flexible coupling and direct drive.  The timing belt was T8 timing belt so not even HTD profile which has more backlash which didn't help.  The FIL factory actually got the location of the Z axis 2nd ballscrew mount out by 2.4mm which i was shocked by.  i double checked measuring against the slideways at the top and bottom of the screw and yeah it was out 2.4mm from factory!  so that is why all the thrust bearings were stuffed. anyway just about to get it running into production.  this machine will be running like 16 hrs a day shortly probably.Lastly just have some photos of the control cabinet.  I wasn’t sure if I would post these.  My wiring is never that clean and currently machine is mid progress so wires everywhere.  But enjoy The system has 7i92m 7i77 7i84 mesa cards And yuhai Chinese servo drives 3.5kwPlus 11kw spindle vfd.  Which I might get another one for the horizontal spindle.The machine was actually working when I got it.  But it took me 30 min to just work out how to turn the 40 year old software on.  And it had old dc brushed drives and 40 year old servo motors and I just didn’t want to have to deal with it.  I run a machine shop in New Zealand full time and work for a lot of larger customers making money and time is money..  so definitely not a hobby here anymore.  we have like 60 tons of CNC gear here (7 machines currently) all running linuxcnc apart from one fagor controlled lathe i haven't bothered yet. So I just didn’t want to deal with issues.  I want a machine that just works for the next 10 years.  I have machines that have worked flawlessly for 6 years so far and keen to run the same system.  You turn it on and make parts.  That’s it.

 
 
 

new spindle motor i fitted.  nothing fancy had it laying around. 



and lastly spindle gearchange setup.  you can buy a 400watt VFD for like 30 usd on aliexpress currently.  so i use those instead of contactors.  so i get nice overloads variable speed. electrical braking and easy wiring all in one.  plus cheaper:)   

Now is working good, thanks.

main photos of machine here

you can see it was a hybrid machine with handwheels also

that means more gears inside and bad servo tuning and more noise

so i removed all that first thing

just a few things i want to noteThe z axis has been redesigned to use a flexible coupling from a old mazak cnc.  They are much better than the standard rubber type.  So I removed the whole belt reduction setup for that axis  which removed at least 0.05mm backlash.  The X and Y still have 0.1mm backlash.  I might put scales on them later but for my first job on machine X and Y don’t really matter.

 

Dudelbert wrote:

I am still struggling with threading.I have tested it at very low speed (100 RPM) in the hope to see something that helps me find what is wrong. But I cannot really say what I am looking at. The result is repeatable, and at least to me it looks like a constant offset that makes it wrong. I have set the cross-slide angle to 0, so that is not the reason. It is supposed to be an M8.



All these tests point me in the direction of the spindle encoder being OK. Are these tests the wrong way of testing this? What else can it be?

 

Take the below with a grain of salt, of course.

Spindle speed:  there is a bug in LCNC which causes a different start point during spindle synchronized motion if successive passes aren't at the same speed.  Constant surface speed is not OK in multi-pass threading.  Same reason folks have reported trying to do thread repair and lining up on a thread by hand, only to wipe out the threads when the spindle is run because the start point is different.

I don't think this was your problem, as I did a screen-cap of your video looking for the start point on each pass.  Pretty constant start point near as I can tell.

It looks like your thread is cutting mostly on the left (leading) side, which would correlate with the Q value you have set.  But it doesn't appear to be going much deeper each pass.

Like you cut one pass deep, then scrape the left side each successive pass without really going much deeper.  The chips look terrible... instead of a 'wire' each pass, you have scrapings.

 

Maybe run another attempt, but change the Q, E, and L values to 0 (straight in),  make sure I/J/K are diameter values, an R-value of 2.0, and ensure you have the spindle in G97.

This might help troubleshooting by taking out a few variables which may be obscuring machine issues.

EDIT - I jut re-watched the video and it's cutting the RIGHT side, not the left.  Like the "Q" value is backwards or something. The tool is moving at the same pitch each pass, but it's offset to the right slightly each successive pass.  Weird.

rodw wrote:

You did include spindle 0 in your tests? That's the ninth, (should be numbered from 0 to 8)
 

Of course I used spindle 0 it's the default spindle and yes they should be numbered 0-8 but if you configure 9 spindles LinuxCNC will not load and has an error. Spindle 0 is the first not the 9th...

JT