Advanced Search

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

Es werden doch verschiedene 7i98 angeboten. Welche genau?

Das 7i98 Bitfile von Baidu funktioniert nur mit der "v1.1", lässt sich aber auch auf eine 7i92 flashen, weil es in Wirklichkeit ein 7i92 Bitfile mit 3 Kanälen ist, statt 2. Die 7i92 zeigt dann 50 Pins an, brickt aber nicht. Trotzdem nicht nachmachen!
Wenn man dieses Bitfile auf eine 7i98 flasht, die dem Original entspricht, brickt die Karte und sollte sich nur per JTAG wieder richten lassen.
Die Pinbelegung ist auf meiner großen 7i98 nicht angeschrieben, ist aber mit gleichen Pins des FPGA verbunden, wie die 7i92 oben in meinem Bild. 3.3V Pin ist der quadratische.

Sowohl die 7i92 oben im Bild, als auch die 7i98 in voller Größe funktionieren mit originalen Bitfiles von Mesa. Die 7i98 "V1.1" funktioniert nicht mit originalen 7i98 Bitfiles, es lassen sich aber, neben den Bitfiles von Baidu 7i92 Bitfiles von Mesa flashen, ohne dass sie brickt. Die funktioniert dann aber in EMC nicht, das dann eine Hostmot2 Fehlermeldung ausspuckt. Die "V1.1" funktioniert also wirklich nur mit chinesischen Bitfiles. Eventuell kann man selbst ein Bitfile machen, ich habe es aber noch nicht probiert, da ich noch keinen PC dafür habe und die AMD Software auf meinem Raspberry nicht laufen wird.

Beim Flashen sollte man bei allen Karten wie folgt vorgehen:

sudo mesaflash --device ethernet --addr 10.10.10.10 --write bitfile.bit --fix --fallback
sudo mesaflash --device ethernet --addr 10.10.10.10 --write bitfile.bit --fallback
sudo mesaflash --device ethernet --addr 10.10.10.10 --reload --fallback 

sudo mesaflash --device ethernet --addr 10.10.10.10 --readhmid  sollte dann die neue Pinbelegung ausspucken. Falls die Karte nicht gefunden wird, funktioniert die Firmware nicht und wird die Karte bricken, wenn man sie in den normalen Bereich flasht. Falls die Firmware nicht funktioniert, trennt man die Karte von der Stromversorgung und verbindet sie wieder, dann läuft sie wieder. Das Bitfile sollte man dann nicht mehr nehmen.

Falls das Flashen funktioniert hat und die korrekte Pinbelegung angezeigt wird, geht man dann weiter wie folgt vor:

sudo mesaflash --device ethernet --addr 10.10.10.10 --write bitfile.bit --fix 
sudo mesaflash --device ethernet --addr 10.10.10.10 --write bitfile.bit 
sudo mesaflash --device ethernet --addr 10.10.10.10 --reload 

Das Bitfile ist dann dauerhaft geschrieben und ist auch nach dem Trennen der Stromversorgung im Flash gespeichert wird also immer automatisch geladen.

Diese Prozedur ist auch in der chinesischen Anleitung so zu finden.

Die kleine 7i98 "V1.1" würde ich nicht noch mal kaufen, da die original Bitfiles von Mesa mit der nicht funktionieren (es sollte aber möglich sein selber welche zu schreiben). Die oben gezeigte 7i92 und die 7i98 in voller Größe entsprechen aber dem Original und funktionieren mit den originalen Bitfiles von Mesa. 



 

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

Thanks for confirming that jitter itself is not the issue. This was expected with my tuning in place..
One of the difficulties with Ethercat, is that there are no IP addresses on the network to test network latency against. If this was a Mesa card, we would do that with sudo chrt 99 ping -i .001 -c 600000 -q 10.10.10.10 Perhaps there is an alternative method.

I think it can be assumed on a properly tuned Ethercat Intel NIC (like yours) that network latency is not a factor. Ethercat has an inherent advantage over Mesa because of its customized network protocol that uses significantly less bandwidth due to smaller packet sizes. The main network latency culprit is coalescing which has been disabled, SMP affinity has been used to ensure the NIC interrupt is running on the same core as Linuxcnc and a number of other optimisations that could introduce network latency have been tamed.This is confirmed where we see a substantial tightening of the Standard Deviation in before and after latency-histogram tests (more than halved from 2.3  to 1.1 usec on Mike's PC). This means the system is much more deterministic with fewer latency spikes (eg narrower bell curve, much more consistent timing on the servo thread).

It all comes back to your environment. eg a configuration issue or a problem with the ethercat system itself (ether the Ethercat master or the linuxcnc-ethercat driver. CNC is a very small subset of what applications the iGh master is used for. Its mostly used on factory floor automation. This is why I find it hard to believe that it has a problem as if it did, the Igh issues register would be flooded with reports and it isn't.

So by my analsyis,  the issue has to be a configuration issue or the linuxcnc-ethercat driver.