Advanced Search

Hi,

I'm trying to change tool offsets on the fly, in order to use a grinding wheel with two workplaces, one at the front to machine my part, and one at the back to refresh the grinding wheel with the diamond wheel. For other reasons (I have 4 axis, X, Z, U, W and two grinding wheels attached, one on X,Z and the other on U,W), I can't work with the tool diameter (since I have two different diameters).

So, I want to change from +X offset to -X offset when I work at the front or at the rear of the grinding wheel. And that's where I try to switch with G10 L1 P1 X[#5401] but it doesn't work. As it may come from my setup, I gone back to simulation sample configuration. It works in Axis simulation sample, but not in QtAxis simulation, neither in QtDragon. So it seems to be related to Qt.

This is working in Axis but isn't in QtAxis or QtDragon :
G0 G54 X0
M6T1
G43
G10 L1 P1 X10
G43 (here G54(X) is 10)
(debug,#5401) (show -10)
G10 L1 P1 X[#5401]
G43 (here G54(X) is -10)
(debug,#5401) (show 10)

This is working in QtAxis or QtDragon (double call to G10 ) :
G0 G54 X0
M6T1
G43
...
G10 L1 P1 X10
G43 (here G54(X) is still -10)
(debug,#5401) (show 10)
G10 L1 P1 X10
G43 (here G54(X) is 10)
(debug,#5401) (show -10)
G10 L1 P1 X[#5401]
G43 (here G54(X) is still 10)
(debug,#5401) (show -10)
G10 L1 P1 X[#5401]
G43 (here G54(X) is -10)
(debug,#5401) (show 10)

I don't understand why I need to call G10 twice in order it works. Since I want to inverse the value, I'm not really confident in calling twice the function...

Any idea on what's is going on ?

Regards,

Ronan

I'll take a look at the branch when I get a chance.

Unfortunately I'm in the same boat in terms of not having been a NativeCAM user previously, so I'm not familiar with the nuances. About a year ago I did manage to hack-and-slash the old version to run on modern 2.9.x as a standalone app. Stuff was still broken but I could do the basics like define the workpiece, and create some basic ops.

Does anyone know the last LinuxCNC distro it was known to work on? If one of the old LinuxCNC ISOs works with NativeCAM, it's easy for me to spin up a virtual machine to test it out as it was intended.

Hi lcvette, Ok, so looked at the probe_basic.ini, and apart from the X axis, my setup is the same. Z is 0 to -ve, Y is 0 to -ve, and X is 0 to +ve. So apart from the X axis my information is the same. Is that your understanding?

No worries, I figured I'd ask in case it was something someone else has seen. I was doing some integration testing on the physical machine yesterday and it was behaving fine, so maybe it is just a Virtualbox problem.

PCW wrote:

Yes, 7I96/7I96S TB3 pin 12 is the input common.
Isolated inputs accept +-5 to +-36V signals relative to input common.

If you connect +24V to input common, the inputs will be activated
when grounded (connected to the 24V negative output) This
is the normal way to setup the input for NPN sensors
(or switches with a common ground)
 

Good evening PCW,

Thank you for your help. I have attempted to draw how I would wire up NPN NO switches to the Mesa 7I96S.

I will have 8 NPN NO sensors (www.makerstore.com.au/product/elec-lj2a3/), but in the drawing I show only two.

Would you be able to check if I am wrong, please?



Thank you and best regards,

...behai.

So i was watching the pid.x.output in halshow and it pretty quickly ramps up to 10 in an effort to correct the position error.But... I am showing only 10-12 mV coming from the card to the drive.

It may be expected. one side of the kerf is not always square so the direction (clockwise/anticlockwise) can make a difference. I think it is to do with the swirl in the gas or something.

It's much better than that. The THTIC pcb accepts floating or grounded. It only cares about the + and - leads for torch voltage, and it doesn't matter if they are already geared down to low voltage, connected to ground or to protective earth or to the electrode or anything. Below 1 kV though.
But I am looking at redesigning this.

An alternative could be to use a barcode scanner. These will plug into your computer as a HID keyboard device. There are some small barcode modules that are RS232 devices. www.aliexpress.com/item/1005007002453623...OfpGuWBoClGYQAvD_BwE

Yes, you would need to digitize the barcode and opencv sounds as good as any. It may have a barcode parser.
To do it yourself you would first need to determine the barcode symbology
There is a phone app called Barcode Data Decoder which will do this.
assuming a 2D symbology, barcodes usually have a start and a stop sequence. Barcode characters are made up of bars and spaces. These are defined as being multiples of the narrow bar width. If you are generating barcodes on a Zebra ZPL printer like I do, the narrow bar is defined as being 1,2 or 3 pixels wide (@203 dpi). Wider barcodes are easier to read. 1 pixel wide narrow bar is nearly impossible to read.

So then you can study up on your symbology and understand its structure.
If you are choosing the symbology, CODE39 is probably the easiest to parse at a low level but its not very compact. Code 128 is more compact but  harder to parse. ref: en.wikipedia.org/wiki/Code_39

if you have CRLF as line endings, there is a command line program dos2unix (might need installing) that will clean it up.
In Windows you can use notepad++ and it has settings to talk in linux format (no CR)