Advanced Search

Nah my images do work out the box, fark I can actually test them before releasing them in the wild, so far the zram issue has only affected one user. Which whilst I have wanted to put up a new image with the fix there has been push back.
The issue that seems to be with the RPi images is that users think that everything is the same as the images from Raspberry Pi, it's like they can't seperate the board from a particular OS.
The fact that I can run mine with either a 7c81 clone that I've put together myself or a Spartan 6 Dev board with an ethernet interface both running slightly modified hostmot2 firmware proves that it does work. Oh and the RPi platform is younger than the whole Linuxcnc project itself....
But an x86 platform is the best bang for buck, no 2 ways about it. You buy a PC and it's complete ready to go. An RPi5 will need a case, PSU a secondary board to run a NVMe drive or a SATA adaptor board if you want something more spritely than an SD card. The x86 platform is tried and true, it works, it's common, it's rugged and has been used it 54 billion installations by Tommy alone this month, as my estimates go.
The only advantage of the RPi platform is size, tho an Odroid H4 or the older H3 isn't much larger and maybe the SPI interface. The mini HDMI connectors are a pain. In saying that waveshare does do some nice boards that plugin to the existing HDMI, power and audio connectors to bring them out to the same side as the USB & ethernet, a nice NVMe adaptor and a aluminium case to suit.

Quiet PC will mean nothing in a workshop.
I've never been a fan of the Atom platform, those small form factor PC's run hot, even just sitting in an open room my industrial PC running pfsense needs a reboot every day or so in summer.
Your mileage may vary but just be aware of the heat issue.
If you want dual NICs in a small form factor I'd choose an Odroid H4 and just bung it in the CNC enclosure, my H3 has never given a issue, even when running in the Australian summer.

Alright.
Based on my research from the last couple of weeks, I've come up with the following plan and list of hardware for the retrofit.

Servos
Replace the dead 611 Simodrive system and associated axis motors. (I would like to reuse the Siemens motors, but refitting the encoders looks like a headache at this stage)
I'm looking at the Leadshine EL7 drives and associated motors. These come in 380v 3ph. Documentation seems good and the prices aren't bad direct from Leadshine.
Run these in via analog +-10v signal. Position feedback via Linuxcnc. Ideally run battery box encoder cables to keep position even when powered off.

Spindle
Retain the original 9/11kw spindle motor. I'll test the poles on it when I'm back, but I see no reason to not reuse it.
I've already got a good deal on a used Delta VFD110E43A. Paid less than 20% of a new one.
I'll have to get a braking resistor for this.
Run the original spindle encoder (or replace it) back to Linuxcnc for rigid tapping and spindle orientation.

Control
Looking at the following Mesa boards:
7i97T to handle analog control of servo drives, spindle VFD and all encoder feedback. Some I/O.
7i84 to handle additional I/O. Tap into the original Bridgeport relay boards to control tool mag, air solenoids etc.
7i73 to handle control panel keys, rotary encoders, MPG etc.
Coofun CK41 Celeron J4125 mini PC 
27" ELO touchscreen (got a lead on a cheap one here, might be a little big though)
A few panel buttons, MPG and rotary encoders for the interface.
GMOCCAPY looks like a great choice and reminds me of the Heidenhain control, which I've really learnt to love. I wish my Fanuc machine was more like it!

Other than the drives, vfd and front interface, the plan is to retain as much of the original control and wiring as possible. As previously mentioned, it doesn't look too hard to tap into the original I/O feeds from the Heidenhain. I also spent some time earlier in the year replacing all the capacitive snubbers on these control boards (with ones that don't light themselves on fire!) Fresh contractors in some spots as well.

Retain all the original breakers and transformers. There is a large contactor, breaker and transformer (415 to 380v) for the servo drives which I'd very much like to reuse (and not rewire!)

Let me now if any of this sounds entirely wrong or you have better ideas on how to execute. While I've played with cnc machines for a while now, this will be a my first experience with Linuxcnc feedback loop on servos/spindle and controlling a tool changer. 

Many thanks,

J 

What's going on with these Biesse's? Are they getting completed?

Found the solution by motivating tommylight to take a detailed look at it , spent him some hours of his night life Jokes away he is a master.
Thank you Tommy

Oh good, someone else replied about the RPI, i was going to go postal!
For 35$ it is magnificent, even 50$ is OK mostly, not a single cent more.
For 100-120$ i can get old Lenovo X1 Yoga, full PC with touchscreen, battery, and much more powerful than RPI.
Also:
PC: download ISO, install ISO, reboot, copy config, run machine!
RPI: download IMG, no not that one the other one for V5 with 4GB not with 8GB or 2GB, write image, boot.... for a while, nothing works, fix wifi, fix power options, fix servo period, use raspiconfig, edit config.txt, fix whatever Unknown mentioned, reboot 20 times, find another power supply, find a cooler to glue to it, find a faster SD card, it crashed ... boot loop, start over. Oh hell no, never again.

As always, great starting points. I'm waiting for my EL2502, although the EL2521 seems to work just fine. Thanks, Corbett and Rodw.

The way I understand it, when I command a rapid move, the Mesacard wants to give it the full 10V, leading to a really rapid move on the motor, way to fast for what linuxcnc anticipated, and that will cause some issues.

 
That's not actually what happens. With velocity mode servos, tuning LinuxCNCs PID FF1 term is what mainly
determines the output voltage correspondence to requested velocity. If FF1 is tuned properly, the analog
output voltage will generate very close to the correct velocity in the drives. Any small per cycle or
cumulative errors are corrected by the P term position feedback.

One way to get a good initial value for FF1 is to set the analog scaling so it is equal to machine units per second
at 10V. In this case FF1==1.000

 

Yeah! Just as soon as I can figure out just what I'm missing to get a piece of gcode to run after loading, sure. Once I open a .ngc file (says it doesn't know what an .nc file is?????), nothing I do will allow me to click cycle start. The cycle start button is never active.

I have more than a few questions and the most of them I don't even know what to ask. Never the less, I keep hacking away.

There is a thread with a guy integrating a cm carrier board with a 7c81.
The RPi5 works but it's a very expensive option compared to an ex corporate PC. The only real advantage is size and that's about it. The RPi5 images work out of the box, but do require the zram fix mentioned in the big thread, it's not a game killer but can raise its head.
Having a RPi5 and 3rd Gen I5 running for testbeds the i5 is definitely the one I'd choose for a build.
For my mill I running a odroid H3 and can not fault it, this has been replaced by the H4.
As for pre-built control boxes, any that rely on the parallel port can be used with a 7i92 for an ethernet option or a 7c81 for SPI with a Raspberry Pi. Some of the issues I have with them is use of DB9 connectors for the Stepper motor connectors. Most of them are quite compact which raises issues of heat and airflow.
I prefer to build my own, lots of room for air flow, the ability to keep the mains and signal wiring well seperated, on side has all the mains, the other side has the low voltage signalling.
I guess if that isn't part of your skill set then an off the shelf control box might be the option if you have the funds.

I updated everything again and created a new configuration. 
Now the spindle zero value is saved in the var file, but in Probe Basic, after closing and reopening it, it shows the value 0, but the value I entered remains in the var file. 

If I enter a value of 227.0000mm, for example, the value always remains in both the var file and the interface. However, if I enter 227.5456, it is saved in the var file, but then it appears as 0 in the interface.

Welp, homing switches were 100% inverted.

Homing now works on Z and Y, I have a wiring/driver/stepper issue to diagnose on X.

Thanks for that, I will review the documentation and try implementation later today.

John

Maybe i was not detailed enough, all configs have search and latch velocity positive for both, OR negative for both, plenty of those configs, only one has one joint where those two values are not the same direction.
To be more helpful, use Rod's advice and slow down everything to a crawl so you can actually see what is going on.
Before that, do absolutely make sure the motor direction is correct.

Actually, the sign does matter because I have had machines where one side of the gantry does not home until the sign is flipped!