Advanced Search

of course, the 0-10V output voltage is the standard output, regardless of the others I want to input.

I am "internally hurt" by multiple signal processing, so I suggested that I also output a frequency signal that can be connected directly to the encoder input. or send it via any serial port / UART.

but ok. let's start with the basic 0-10V.
unfortunately I do not foresee an upgrade option for the end user, so I have to program everything before shipping.

But I see no problem in sending new versions.

for details you can contact me directly.

proma-elektronika.com/contact/

 Great! Let's move ahead.

Let's talk about 0-10 volt range first.
The Mesa THCAD is a voltage to frequency converter. The THCAD10 has a 10 volt full scale. The THCAD 5 has a 5 volt full scale. The newer THCAD2 can be configured to either have a 10v or 5v full scale range. For your hardware, the 10v range sounds best.
We read the frequency using an encoder A input (usually on a Mesa card) and then scale it internally back to a voltage. Usually we set the THCAD's on board frequency divider so we read 1/32 of the frequency when sending it to Linuxcnc.

To receive a frequency, we would simply connect your hardware direct to an encoder A input and not use a THCAD.

It would be easy to apply a mathematical function to the encoder frequency to convert to a voltage in a real time component written in C.

There are other options to read both voltage and frequency. For example, appropriate Ethercat slaves for both voltage and frequency are available.
I think for Ethercat I would prefer 0-10 volt.

Finally, I might mention that for plasma torch height control, we adjust the height using external offsets (this offset is external to the motion controller). A scaled count (much like a MPG) allows us to take the input and output a height adjustment of the error. But because you output a distance, it might be possible to manage height control via one of Linuxcnc's PIDS.
 
Anyway, if you have a contact us option on your website, let me know, and I will reach out to take things further.

newbynobi wrote:

May be the driver has a setting to set the repetition rate ?
My one reakts with a long touch like preesing the right mouse button. So I was also forced to set that time longer to be able to hold down the touch buttons for longer.

Norbert

I will look into the keyboard repeat settings to see if that changes anything, I'll have to look it up as I've only ever used windows so no idea where those settings would be but I'm sure google will let me know.

Hey there Roslyak,

I'm having problems getting CSP mode working on the same drive too. Did you end up having any success with your configuration?

From what I can see, the control word PDO is not being passed properly and it never enables the voltage (control word = 1, I believe) and the motor does not spin, even though I hear its capacitors buzzing. In the HAL config I see the control mode pin becoming 0x0000000F, which doesn't seem correct, yet it does become 0x00000002 when I stop the (unsuccessful) movement, so quick stop works. Otherwise the drive enters OP mode properly.

The encoder feedback is also 0 at all times, but I'm wondering if that matters at all, considering not even the control word is in working order.

Would you mind sharing your XML so I can see if I've even got mine set up properly? From what I can gather, the PDOs of the DELTA drive change depending on what mode the EC master puts it in, so that is a bit confusing for me.

I considered ordering the EMC-MC01 card too, but my encoder is a sin/cos incremental one. Looking at its PG pin documentation, I am having doubts if I will be able to even connect my encoder to it, as the card only has 4 active pins (my encoder has 9+).

The PG card I have right now is the EMC-PG01H, which should work for sin/cos encoders, yet I'm not sure if it supports CiA402 communication.

I seem to have no good option - either a PG card that supports my encoder, but doesn't support CiA402, or a PG card that supports CiA402, but doesn't support my encoder...

EDIT: Do you mind also sharing the exact Tamagawa encoder you have? I have little experience with them so it would be great to know if I can figure out if an adapter of sorts that could solve my issue exists.

This is what the config looks like right now:Same for all axes. The machine units is mm. Except the vertical MAX_VELOCITY is 40.0, because I would need to reduce the servo pulses per revolution in case I want to go higher (currently limited by step timings).

FERROR and MIN_FERROR are just the defaults from PnCconf (I think). Based on the current tuning, I might reduce them by an order of magnitude. Provided they work how I think they do. I need to look into that at some point.

fantastic.

There is still a possibility of implementation, so I would like to adapt it to LinuxCNC as much as possible.

I am not sure if it makes practical sense to process data multiple times, which loses measurement accuracy and introduces additional errors at each stage C/f -> U -> f ...

i can made frequency output directly in sensor.

I see that the THCAD5 card processes voltage to frequencies in the range of 100 kHz - 1 MHz, but I can adapt to any frequency (lower frexuancy could be directly monitored in many "less efficient" controllers and send via cable easyer ), it can also be a PWM output or serial communication, which I can send a ready-to-use height without the need for the CNC system to process the signal, which in my opinion would be the best option.

In your opinion, what would be the best option?