Advanced Search

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.

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. 



 

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.

Hey guys 

just thought i would post this latest retrofit i am doing currently.  I know when i was just starting out 10 or so years ago i lived on this forum and really really appreciated the info on here.  So I am trying to post more so that maybe this can stay as a record and maybe help someone.

Retrofit is almost at the end of the process.  And I don't really have any questions currently though advice is welcome   So i thought maybe the show your stuff category would be the right place.  Mods feel free to move this..  

just editing to add a youtube video of machine.



machine is made in 1980s so at least 40 years old.

it has a vertical spindle on a over arm plus a horizontal spindle

all BT50

The reason i bought it was this has a 2m travel in the X axis  Y axis is 700mm and Z axis has 1150 max workpiece height

max speed is only 1800 rpm but that is ok.  i will be using larger tools on this and mainly only rotating at 400 RPM.

this has a gearbox and 4 speeds for both spindles, hopefully the photos make sense.  I will probably only use one gear and make it a two speed and use the VFD for the rest of the speed changes as that will allow enough torque and i think the extra gears are not needed.  time will tell i can always change that.

Photos coming in the next post

 

Damn, I was afraid of that, unfortunately I had to leave the workshop… just missed it. Thanks for doing it right away today! Sorry for my vad Timing....Thanks a lot for exporting it, I’ll test it tomorrow evening right away!I’m afraid I won’t be able to sleep tonight :O

Surmetall wrote:

Thank you for your help, and sorry for taking up your time. I hope to learn this myself as soon as possible so I won’t have to bother anyone.The exported file was called “.tnzip” for some reason I have no idea why. I renamed it to “.zip” so I can upload it here.
 

here is output.. check it all

Greetings everyone. Today I went to the customer's office after the company closed at 5 pm. I just got back at 8:30 pm. I had the chance to do some more testing, and I have to agree with Grandixximo.
I don't know why, perhaps I was in a hurry to not down the customer's machine for too long, and I made some mistakes.
The jitter results:
Debian Trixie, kernel 6.12.74-rt, latest Grandixxmo patch, Grub command line optimization (isolcpus, etc.) with 4 glx files open, 2 browser windows open, full-screen window movements, switching between different desktops, max jitter 65 microseconds.
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
Pin pll-out oscillates -5 to 5

I tried the commands:
ethercat upload -p 0 -t uint16 0x1C32 0x02
ethercat upload -p 0 -t uint16 0x1C32 0x03
ethercat upload -p 0 -t uint16 0x1C32 0x05

but it returns the error failed to upload sdo : no buffer space available

Debian Buster, kernel 4.19-27-rt, no optimizations on the Grub command line, with 4 glx files open, 2 browser windows open , full-screen window movements, switching between desktops, max jitter 95 microseconds.
With the same Grub optimizations as Trixie, max jitter is 75 microseconds.
With refClockSyncCycles=1, it easily emits noise.
With refClockSyncCycles=-1, it works flawlessly and without Grub optimizations, which with GRUB optimizations
pll-err pin from -1800 to 2000
pll-out pin oscillates with only two values: either -1000 or 1000

So I deduce that even Trixie has lower jitter than Debian 10, but for some reason, Debian 10 lets my machine work and Trixie doesn't.

It has its own GUI....I have not tried it with other UI's, but should be able to work. You can save the g-code and load it in any Linuxcnc ui.

In the readme->quick install section it mentions the 'standalone' mode