Advanced Search

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.

When i start linuxcnc with just setp gladevcp.table1" in the postgui i receive this error message



Any ideas how to fix it?

I found this  github.com/LinuxCNC/linuxcnc/blob/2.9/configs/sim/hitcounter.py
I created a file hitcounter.py in /home/cnc/linuxcnc/configs/Fräse/ with the contend from the link

A little different error

Debian BookWorm 12.0 and 12.1 had this issue where it would complain about missing raspi firmware, 12.2 and 12.5 did not have this issue, i did test and build the ISO and no issues were present, so the only point where the issue would transfer to new ISO is not cleaning the build environment before building the new ISO.
Although he keeps insisting Debian pulls the new installer while building the ISO, i know for sure Linux Mint does not pull anything, and neither did Debian when i built the 12.2 and 12.5 ISO.
IIRC 2.92 or 2.93 ISO did not have this issue, but it cam back, so that remains a mystery to me, maybe build was done on another PC and later went back to "old" PC ...

Thanks for a help, I am not big pro in Linuxcnc. 

Spindle.0 is Delta C2000 and ethercat card running in Velocity mode. So I made comp file that sending enable signal to it and the rest is usuall cia402.

Spindle.1 is SD2S via CoE. 

If I have just one spindle.0 its running well. Then if I add spindle.1 it runs well but spindle.0 receive just setpoint without enable word.
 

Marko6 wrote:

Thanks. It works now.

However I have spindle.0 and spindle.1 and as soon as I added spindle.1, spindle0 stopped working (Linuxcnc - Qtdragon only sends the setpoint.0 value and no enable signal). Strange.
 

Upload your config ... I can check it.. more detail as ..

 

Thanks. It works now.

However I have spindle.0 and spindle.1 and as soon as I added spindle.1, spindle0 stopped working (Linuxcnc - Qtdragon only sends the setpoint.0 value and no enable signal). Strange.

After replacing the processor there are no warning messages or the machine stops.

I made a new video a little long but it is a compilation of all the operations. The hydraulic chuck are missing

I hope it is understandable - my english is way too rusty to explain such a problem

github.com/LinuxCNC/linuxcnc/issues/3583

This is from your 'gmoccapy_postgui.hal':
As has already been stated, you cannot reuse the same halpins use the signals they were assigned to.
Maybe this helps to explain some of the basics:
linuxcnc.org/docs/html/hal/intro.html

Yeah Rod reckons it's a Debian issue.

Rods take on it
forum.linuxcnc.org/9-installing-linuxcnc...amd64-version#332160

Every time a user is hit by the issue they start a new thread, I've tried to start a sticky, but as usual search doesn't get used, so it's a page or 2 walking a user through it.

But yeah it does appear to be frustrating. Maybe it requires pulling apart the squashfs file that the installer uses and manipulating that. I dunno just talking to myself.

tommylight wrote:

Not my mess, luckily, but i hate dealing with it as it's been dragging for over a year now, all because someone did not clean the build environment before building the ISO.

Can you explain to me exactly what the problem is? I have not been able to keep up with the forum for quite some time. 

I was aware that there was an issue of some sort, but though that it was in upstream Debian?