Advanced Search

C isn't so hard, try it!

It's a nice, simple language.

Try out Arduino, it'll teach you to be a C master.

You'll start to end sentences with a ";" after while!

Ouch. I swear I knew that before. Thanks a lot for your reply.

For anyone else that stumbles on this, here is what I added to my personal operations manual:

Q: Ohmic sensing is triggered early
A: This is most often caused by slag or water getting into the shield. 

With the torch shield away from anything conductive, tap the ohmic test button. If the Ohmic light comes on then the ohmic sense circuit is shorted. If you are doing test cuts on scrap, tap the Torch Pulse button to blow out any water in the shield. If that doesn't work, turn off plasma cutter and blow the tip with compressed air. If this does not work, remove shield and clean out any debris. Look for slag that is stuck to the electrode and/or shield cup. 

In the case of slag, consider increasing pierce height as this almost always happens during pierce. In the case of water, add G0 to your program to rapidly move the torch away from water being sprayed by the a torch during postflow.

Thank you for your responses.
I see now how to call another subrutine. If I'm in a running subroutine and stop it, do I have to end it (END SUB) before I call the new subrutine?

I meant "work offset".

If I am undestanding this L20 P0 would change the axis for all subroutines relative to the machine coordinates and not change the WCS offsets for each location i.e. G54...5,6,7. Is this the same as using the Axis Screen offset for P0?

Essintially the program ran the first opertion to all 4 locaions then lifted up and stopped. I want to be able to move it back to the first location and change the tool and set the Z work offset for the nest operation.

Many thanks

Raw counts will be set to 0 when LinuxCNC starts so its still
just a relative count number.

What is the spacing between index marks on your scale?

You have

setp hm2_[MESA](BOARD).0.encoder.00.filter 0

(on all axis) You might try:

setp hm2_[MESA](BOARD).0.encoder.00.filter 1

In case it's a noise issue.

Yeah, sorry, I copied them from a 7I96S halshow and forgot to delete the "s"

Thank you very much, I will try those fixes and get back to you.

I also wanted to mention that when we manufacture this machine with new pc hardware and this new software we get the latency warnings but the machine performs without issues. I don't know if that is relevant or not.

Fixed the outputs and inverts for 7i95t, 7i96, 7i96s, 7i97 and 7i97t.

JT

Yes, that is the BOB with very slow optos, and as long as you get latency warnings, the steps might and will be missed, so
-Set the base period to 100000
-set the drive microstepping to 1600
-set the parport reset time to 10000 in the hal file
-set the step time and space to 10000 in the ini
If you still get latency warnings, in BIOS:
-disable hyperthreading
-disable TPM
-disable "aggressive PCI-E power something or another"
-disable any power saving option, like C states, turbo, speed step, etc

The drift might be something physically slipping. Mark any shaft-to-pulley or coupler joints to be sure.
Hopefully it isn't the encoder slipping on the motor shaft, that would be very difficult to detect or fix.

It is unlikely to be lost steps in a closed-loop system, and also unlikely to be lost encoder counts, but it's not entirely impossible.

I don't know why there is a 22.2222 factor on your rotary axes, it feels like that constant factor could be in the INI scaling.

In fact your userkins appears to basically be a trivial kinematics? Why not use trivkins?

Maybe you are running a run-in-place system, so LinuxCNC is running from linuxcnc-dev but halcompile is placing the compiled kins in the root structure?
(But that wouldn't explain why edirting the C and recompiling works...)

I think you are being confused by an old version of 'userkins.c'. Note that

will not create a 'userkins.c' file at all, it will directly create a 'userkins.so' and copy that to the appropriate folder.

linuxcnc.org/docs/html/man/man1/halcompile.1.html

If things are working after
'sudo halcompile --install userkins.comp'
then you can delete the 'userkins.c' file.

You can certainly do this with standard LinuxCNC, so I see no reason that it wouldn't work with PB.

You basically just switch the axis to joint names round. (and, in fact, in many cases you may not even need to do that)

For my horizontal mill I think I used my standard horizontal confic, where table in-out is Z and left-right is X (and I just jogged Y to set tool height)

Hi Tommy.

I implemented the changes you suggested except for those done on the Bios as I do not have access to it over AnyDesk.
After implementing the machine would home correctly as normal, but when running to a set distance the arm would halt after moving about 20 mm and give an error, "joint 0 following error" and this process of moving slightly and giving error happens every time any distance is entered. I also received latency warnings for 100000. I have attached a picture of the errors.

I reverted the settings back one by one and machine ran as it did before only after all changes were reverted. These were the changes I made:

• Base_Period = 100000 >>> set back to 500
• Drive microstepping = 1600 >>> set back to 2000 pul/rev 
• Parport reset time = 10000 >>> set back to 500
• I added STEP_SPACE and STEP_TIME to the "EMCMOT" section as I did not already have it in the ini file. STEP_SPACE & STEP_TIME = 0.00001 >>> I removed these two settings after.

Any thoughts on how to proceed? Thank you for your input so far.
 

mikereid0817 wrote:

Hi Andy... I am muddling my way through this and have things working really well, except inputs. Gpio reads gpio13 fine in python, hal_gpio always shows high in hal scope, meter etc. Any ideas? Is there a way to set gpio characteristics with hal?
 

You can try setting the various modifiers for GPIO13 and see if that helps.
opendrain
opensource
biasdisable
pulldown
pullup
As described in linuxcnc.org/docs/devel/html/drivers/hal_gpio.html#_usage

I am not clear if you are saying that it is always set and the input can not be changed, even if pulled low?

Have you checked with gpioinfo that nothing is claiming the pin?