Advanced Search

greg23_78 wrote:

ok, so the 160 V on your website corresponds to a peak voltage?
For the input voltage, for reasons of economy, a DC power supply to manage the 6 motors is likely to be expensive.
What's more, being in Europe, I have to manage with 240/400 volts. It's easier to find an auto-transformer to output 110V and add a 3-phase bridge rectifier with capacitor.
is it possible to supply your amps with RMS voltage?

 

Sorry, I really ought to change that.  The amps won't blow up at that voltage, but you have a high probability of having nuisance trips of the overcurrent fault logic.  So, I really recommend 122 V as the highest DC supply voltage.
for resolvers, is there a way to manage robot position data with batteries (like kuka) without continuously powering the computer with linuxcnc open? because manually homing robot axes could take a long time ..

For the input voltage, for reasons of economy, a DC power supply to manage the 6 motors is likely to be expensive.

A simple power supply can be built with a transformer, rectifier and capacitor bank.  In the US, there are commonly-used "step down transformers" that have split primary and secondary windings.  These can be strapped to give various voltages, and are used in large machine tool controls to provide 120 and 240 V from 480 V mains. These can often be found at scrapyards for the salvage metal price. To get 122 V DC with a capacitor-input filter, you would want about 86 VAC from the transformer.  Possibly this can be arranged with a buck-boost autotransformer before the isolation transformer.  If you can find suitable tranformer(s) surplus, this can be done quite cheaply.  The amps definitely need isolation from the mains, and DC input.

for resolvers, is there a way to manage robot position data with batteries (like kuka) without continuously powering the computer with linuxcnc open? because manually homing robot axes could take a long time ...

Our resolver converters have no way to provide absolute position via quadrature output.  That's one of the reasons why some vendors use exotic absolute encoders.  Also, most robots have gearing on the joints, so the motors make many turns for the full motion range.  Fanuc serial encoders, for instance, report # of full turns from the home position, but need a backup battery..
Homing should not be a huge issue, especially if the robot is placed in a good pre-home stance when LinuxCNC is shut down. LinuxCNC can do a sequenced home procedure where each joint is homed in a specified order to be safe.

Jon
 

Hi Mark,
Nice to see that the bearings look okay.
In the 70's we had a 4 foot diameter spherical roller thrust bearing for a 150 tonne rotary regenerative pre-heater. It arrived with false Brinelling. SKF took it back, reground the races and fitted new rollers. It might be possible to do that with these bespoke spindles if there were damaged.
I re-read the docs for my spindle and realized I didn't include the attached page. It's not all that applicable to your machine except for the end float I think. I heated my bearing to 50 C at they explain but I made a silly mistake. I used my paint stripper gun on low and almost immediately the grease started to smoke. It seems that the grease heats up much faster than the steel. So I repacked it and put it in my Siemens domestic oven. It has a nice thermostat that goes low enough to proof dough. It seems the key thing is to make sure that the races are all hard against the end float shoulders. And yes I put it into may Emmert pattern makers vise and hit it repeatedly with a rubber mallet. I've fitted it with wooden face plates.
It seems they set them up with a few micrometers float and are fussy it isn't larger. It certainly ran hot on first start even at the lowest speed. So I went through the whole stop, cool, start procedure at every speed. And it still got a bit hot at full speed until it bedded in later.
So I think the idea is the spindle runs hotter than the surrounding parts as the heat has to get to the fins behind the cover plate. That means the end float is eliminated and the bearings are pre-loaded. In you case you have  shims. I think I would make a similar tiny float when the races are seated and remember to rotate the shaft to settle the balls and cage. When these taper rollers or angular contact balls operate they nutate like small gyroscopes. The races must drive that nutation or at high speed the balls will scuff themselves and the races. I think possibly the tapered rollers in mine have too much gyroscopic moment to run at your higher speed, so the use balls for that?
If you go back you will see I had some issues with the cooling fan being loose. It very important that it blows down the fin slots. I made a bigger copy of you ring lamp. They work great, but be careful it doesn't block the cooling air coming down those slots
The labyrinth seal on my quill was full of muck from the swarf. So I agree that flood cooling is probably better.
Cheers,
David

Hi everyone

I'm new but I've been reading every scrap of info on this forum, raspberrypi.org, raspian.org and youtube on getting my Pi 5/Mesa 7i95T setup working.

I'm a bit rusty on Linux but it's coming back.

I ran though the full install a few times with the RPI5 download from the download page and got most things working - screen, network, apt updates, etc.

But I had trouble getting my 52PI m.2 NVME hat working with my drive (which is not a SATA)

I started looking through the journalctl boot files and saw quite a few bcm2835 and bcm2708 entries, so my first question shouldn't the drivers in question be bcm2712?

I see a few bcm2712 along with the others but I began to worry that I may have 'updated' my system to some older drivers for pi0/3/4 etc.

So I just downloaded:

rpi-5-debian-bookworm-6.6.54-rt39-arm64-ext4-2024-11-06-2037_qtpyvcp_stable_networkmanager.img.xz

I tried to burn it with the Raspberry image burner and it gives me an error:

Input file is not a valid disk image.
File size 6700000000 bytes is not a multiple of 512.

Did I download it incorrectly from Google Drive?
Is my 32Gb eNVME drive to small or an off brand?

Having read hundreds of posts on this WIKI over the last six weeks I'm blown away by time and effort everyone has put into this project.

Thanks for everything,

Richard

PCW wrote:

SPI should work though a Efinix specific top level file would need to be
made from the Xilinx source.  Efinix tools don't automatically
translate "Z" types into tristate pins so you have to export the signal
_and_ enable pins from the top level file. Note for the current SPI source
(GCSPI) The SPI clock must be routed to a FPGA clock pin.
 

Thanks for the quick response, This should get me going in the right direction. Currently I have only gone so far as to generate new .bin files when required for my 7i92t/7i96s cards.

PCW wrote:

Any package is OK
 

Awesome, glad to hear it.