Advanced Search

Just a thought, if this still persists with the installer is there a way to check for the existence of the firmware and remove it if found during the stage when the installer on the ISO removed packages ?
I guess this would have to be a custom script, and a band aid type of fix. You know in case this beast raises its head again.

forum.linuxcnc.org/9-installing-linuxcnc...tion?start=20#336295

Hopefully the above explanation is clearer.

Sorry just to clarify, when running the installer from the ISO image the raspi-firmware is being installed.
Can confirm upon first login to the newly installed system tuning apt purge removes the offending files. This has been confirmed by running find to look for any files that contain the string raspi prior to running apt purge then after running apt purge.

Ok I got it , Guess I didn't pay attention just copied and paste Gmoccapy config to get it working not reading if I needed everything.

Waiting to confirm something by unknown.

unknown wrote:

The installer is definitely installing the raspi-firmware.

Do you mean the Debian installer or LinuxCNC ISO installer?

bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065640

It looks to have been recently fixed upstream.

(I am still not clear if you are blaming me, Rod or Roland Clobus)

Oh cr@p !!!
Thank you for looking into it.

Solved!

To use Single-Step, you must:
1. Press Run ("R")
2. Press Pause ("P")
3. Press Execute Next Line as required (why it's not called Step I don't know) ("T")

Quirks:
While it does single-step, it only does so for motion-related instructions; everything else gets executed and full speed. If there's a way to truly perform single-stepping, I'd like to know.
Due to the above, single-step only highlights motion-related lines, so everything else doesn't get highlighted.

This thread can be closed!

i build a new component to use the I2C port on the RPI4/5 for extra Digital-IO's and ADC's
can be used standalone, no rio needed: github.com/multigcs/riocore/blob/dev/rio...ins/rpii2c/rpii2c.py

That makes it easier to imagine



It should now also be possible to mix FPGA and RPI/Parport configurations.

Oh, there's a new I2C plugin for the Raspberry with pcf8574 and ads1115 support (digital IO + analog inputs / non-real-time).

The installer is definitely installing the raspi-firmware. Did an install in VirtualBox, before running apt anything I ran find looking for anything raspi related and it was there.
Just running apt purge was enough to get rid of it, no need to manually delete any files.
Having a poke around the build config raspi-firmware is not supposed to be installed, but for some reason it's not being respected.
I would say that the post I linked by Rod is not what is actually happening.

I have removed and disassembled the Fanuc encoders, retaining the central shaft that mounts to the tapered encoder mount on the motor's shaft. I turned down a section of this shaft to 15mm which is the bore size of the clamping collar of the new encoders. The encoders are hollow all the way through so I can still tighten the screw that mounts the encoder shaft to the motor. 

 

Turns out that the new encoder mount flanges happen to line up with some holes on the old Fanuc encoder bearing housing, so I repurposed those to serve as the encoder mounts. All mounted on the machine now, everything fits under the original red caps, with one tight fit under the smaller turret motor.

 

Unfortunately I have been unsuccessful in configuring the drives (AB Ultra3000) to engage in self-sensing commutation. I have tried everything I can think of including: 

-swapping motor phases (every possible combination) to ensure motor direction phase relationship and encoder direction match
-adjusting self-sensing current
-swapping A / B encoder phases to see if they were backwards with relation to the motor while also trying the various motor phase connections in this A / B swapped configuration
-double checking and experimenting with Pulses Per Revolution and the corresponding Lines Per Revolution data at the drive. Encoder is listed as PPR while drive data input is LPR as it counts the rising and falling edges therefore PPR*4=LPR

Now I'm wondering if my motor configuration settings have something to do with it (within the Ultraware configurator, some numbers such as Inductance had to be guessed as I do not know how to measure that and havent found info on that yet), but it seems like an unlikely cause. 

No matter what I do I get E39 (self-sensing startup error) a short period of self-sensing testing upon enabling the drive. 

The motor in question is free to spin for the self-sensing routine. 

Which brings me to another problem: the X-axis is HEAVILY loaded as it is a slant bed without counter spring. Currently a brake is on, so if I were to figure out this self-sensing and make it work, or even generate commutation pulses from the incremental encoder data, any startup sensing would have to take place with the X-Axis brake released and have the motor engaged in holding torque so that the whole thing doesnt come crashing down. 

I think I should have bought encoders with commutation outputs   I assumed that the self-sensing commutation would work as perscribed but for some reason I cant get it to work. 

Now I'm starting to wonder if I should run the the buffered encoder outs (that the Ultra3000 provides) into LinuxCNC via the extra Mesa cards I got and use BLDC to generate commutation pulses, send them out to the drives. The only issue is the startup sensing: how would BLDC command the Step/Dir drives to move in order to find the index pulse if the step/dir drives need the commutation signals to run in the first place? 

If anyone has any ideas, even half-baked, I'd love to hear them. 

The Conquest continues. 



 

Well to be fair there is the included Qtvcp too.
You can build what ever you like with it.
Qtdragon uses Qtvcp.

What toolkit is best is probably subjective

I found this video helpful. I haven't tried it yet, but I was not doing it this way. The only thing I don't like about it is that you have to start a potentially bad job running at full speed before pausing and single-stepping.