Laser Head Height Sensor – Looking for a Beta Tester

Thanks Peter for your opinion.
You strongly confirmed my analyses.
because some cards have a limit of 100kHz ( ETHERCAT EL5151for example )
I suggest 20-70kHz (0-10mm) and 10kHz(or 0Hz) = collision

prokopcio wrote:

I suggest 20-70kHz (0-10mm) and 10kHz(or 0Hz) = collision

This is linuxcnc. We will not have collisions!
Maybe  collisions are 5 kHz and our rule is: if < 10 kHz, report a collision

Not sure what all types of laser heads this will work with but I'm about to stick a diode laser on a PnP machine I built but shelved. I'll be doing that in the next few days, I could stick this thing on it while I'm converting it over if that's the type of testing you're looking for.

I use a custom carrier board for a Mesa 7i92. Not sure what other kind IO capabilities that thing has but I think the only suitable input I have is an "SmartSerial" port. That's a 2.5Mbaud RS422 port which is what people tend to use around here for stuff like this since Mesa cards are the king of the hill. I could also swap the RS422 transceiver for a dual RS422 receiver to make it a quadrature encoder input.

hi blazini,
I also think that digital/serial transmission is a very good solution.

I have to think about it because the output that I have available in the sensor is an open drain output and it would require a simple converter but it is not a problem to add it. These are just a few basic elements to adapt to various interfaces such as RS485, RS422, RS232 or UART TTL.

I do not foresee standard protocols such as MODBUS etc. with bidirectional communication due to the too long time of exchanging transmission frames.

I do not want to use a high transmission speed so that the quality of the connectors and cables does not affect any possible distortions.
I want to transmit every 1ms only 4 bytes (start byte, 2 data bytes, crc) at a speed of 57600 but it is possible that I will change the assumptions.
Could you handle something like this?
If you have other ideas, they will be welcome

rodw wrote:

prokopcio wrote:

I suggest 20-70kHz (0-10mm) and 10kHz(or 0Hz) = collision
This is linuxcnc. We will not have collisions!
Maybe  collisions are 5 kHz and our rule is: if < 10 kHz, report a collision

in fact, anything below 20 kHz is a collision.

higher frequencies mean faster response, which is very important for collisions.

Linuxcnc is not really designed for serial transmission in real time.
Yes, Mesa has its smart serial interface that it uses principally for its own daughter cards but its not well developed for third party devices. It would add additional development complexity. Plus it would limit the hardware platform that could be used with Linuxcnc.

Using frequency or a voltage is well understood and easy to decode and support on different hardware
With the emergence of Ethercat controlled laser cutting heads, its important to consider a wider audience and how it can be incorporated into an Ethercat machine.
Also I noted that on some laser cutting solutions the capacitive BCL-AMP is being superceded by amplifiers with a 0-10 volt signal

I think Proma needs to gives some thought on to how to keep their audience as broad as possible. I think that while using a frequency read by an encoder is quite simple and broadly available, 0-10 volt may open the device up to a broader audience but may not have the advantage of sensing collissions etc via specific frequencies.  Using serial communications reduces the audience to Linuxcnc users using specific hardware. I think frequency sounds the most flexible now.

Finally a question about frequencies. How would you sense a void? eg say you wanted to find the material edge so the axes can be rotated around the Z axis to account for a skewed sheet? Or to sense the edge of a sheet when severing it to turn off the laser?