Advanced Search

You can (or should be able to, is best to say) select your own datatypes.
Starting in eeprom_generator. Then for lcec in ethercat-conf.xml you can select the datatype of the created hal pin.
I don't think every combination is possible or makes sense, but to go from ethercat u32 to hal bit should work. For example.

Regarding the Analog voltage output - yes that was the reason to chose that pin - it is DAC capable.
The STM32 is really picky which pin one selects, they all have special functions and are not interchangeable at all.

The DAC also works by placing values ​​between 0 and 1020 volts, which gives values ​​between 0 and 3.28 volts at the output. It could be used directly to control the speed of a VFD by scaling it.

I have been playing with the inputs and outputs of the card and I realized that these are of type u32 and in order to be used in LCN they must be converted to BITs with the conv_u32_bit component, this is because some pins that LCN automatically creates are of type bit, such as joint.N.amp-fault.in, iocontrol.o.emc.enable-in, or any other pin that has been declared as type bit.

That's what you suggested, using STATUS.connect.. I can control the position of the A-axis tailstock.

After reloading the next file, the tailstock is positioned in the appropriate place depending on the dimension of the project in the X axis.

Another thing I want is to re-build the dimensions of the workpiece.

Qt_vismach can update the position of an already built object, but I can't do it to re-build a new workpiece.

I tried adding a new class in primitives.py, analogous to HalTranslate, but it doesn't work.

It would also be interesting to be able to change the colors of some elements, depending on the values ​​of different pins.

How to do it?

that seems absolutely plausible, I would like to try it out later, thanks Chris
 

x or y scaling needs adjustmenf -meaning a distorted shape (that's what it looks like)

You can set the scaling of x and y in 2.9.3 with the INI embedding line by adding something like this:

-o xscale=1.0 -o yscale=1.5

The script calculates fairly correctly if g54 z0 is set to the A-axis rotation axis, and Y0 is above the A-axis center.

This is just a rough idea, to calculate the speed at the tool tip completely correctly, a few corrections would have to be made.

The script does not have a loop, so I run it like this:  "watch -n0.2 ./new_vel.py"

Is there a Z and corner finding touch plate you recommend that Linux already supports?  In other words, is there programming support already developed for particular touch plates?  If so, it seems it would be much easier to use one that has programming already developed.

Interested to see what you recommend.

Some do, but not much so far, and not active here much.
Me neither, yet, but probably should need some editing in hal as mm/m and mm/rev are not the same thing nor the same pin in hal.
As to what exactly, i have no clue.

All Kuka robots i have worked with have resolvers on motors, that is the sine/cosine thingy, not encoders. Those were KR150 and KR320, so much bigger.
Mesa has something that can read resolvers, but you need to find the exact model of the resolvers to know for sure.
Motors might also use something for comutation, but not sure if that is also done from resolvers.
I did a lot of wiring on one of those, but never needed to mes with motors or drives as all were working.
I was not on robot forums for a long time, i was the one who posted the hack to make Kuka robots work in Auto mode when they are factory disabled. They are usually controlled by a central computer for synchronization.

 thanks Chris, it is none proportionality of the figure at all, there is no idea at the moment.

and the single point threadmill test

Hi all

I have big latency issues, using the nvem rt1052 cpp/dma with Linuxcnc 2.9.3.
My laptop is a Lenovo L540 (i5), 12gb, ssd. Latency test shows jitter of about 30-40k with glxgears.
As soon as i turn on the machine the servo-thread goes up to 1.5m average and even up to >5m. Is the Cpu really that much to slow ? It runs perfectly with a mesa 7i96s.
I tried playing around with PRU_base_freq= parameters, nothing changed. Also i noticed in the sample config BASE_PERIOD is set to 0 ? Is this some error or not used at all ?
Also i noticed when the axis is moved fast, the DRO still counts for 1-2 seconds even DTG is 0 ?

-
schnellmued
 

Does nobody really use Probe Basic Lathe?

It doesn't matter whether it's mm/rev or inch/rev, the same effect should occur with both if it's normal that you can't use a potentiometer.

I'd like your help in organizing my project.

i managed to recover a KUKA Kr15 robot but without the control bay.
and i'd like to get my hands on it and learn all about it. “Denavit-Hartenberg (DH) parameters”, ‘genserkins’ ...

After calling KUKA, they told me that only their KRC1 with old electronics was compatible with the KR15-1.

So I'd like to go with linuxcnc.

my first question is about the harware:

after several searches, i could see that the motors were siemens servos with a kuka label. the encoders seem to be cos/sin.

www.robot-forum.com/robotforum/thread/32...0-servomotor-pinout/

As for motor control, I'm a bit confused, on the motor nameplate you can see 1.5A / Uistr 146V / 6000/9000tr. they are in 3-phase AC.

after a long search on drivers, i find many with 200V -400V. I see that all the drivers have an encoder input. Is it wiser to connect the encoders to the drivers or to the mesa card? Are there AC drivers without encoder feedback?

-can a mesa card read cos/sin encoders? or do you need a card between the encoder and the mesa card?