Advanced Search

ve?

Forgot OpenCV, and use a barcode scanner.
I do this way to scan the worksheet and load the G-Code according to the type of part which I need to machine. The bar code scanner act as a keyboard, and I use a few python in the handler.py file to get what I need.

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.