Advanced Search

Sigh, my brain couldn't help but try to fix this. My idea: change debounce() to act like this:

state in out action
neg 0 x state = -delay
neg 1 x state ++
zero 0 1 out=1 state = delay
zero 1 0 out=0 state = -delay
pos 1 x state = delay
pos 0 x state --

(if out isn't persistent, use state == +1 or -1 instead of zero)

      Hi all;I was having this error randomly pop-up while running my level-check routine. Searching the forum I found  Billiiles  response to seuchato's post on a similar topic and applied his suggestion to add some dwell to insure the machine was stable before the next move statement, but I'm still getting random errors during the routine. The routine I wrote uses a touch plate made from 1/8 aluminum plate offset from the table by 5 cabinet bumpers, one in each corner and one in the middle. (See attached picture).I had used this routine and plate extensively without issues prior to a major rebuild of my machine to add a second Y axis to eliminate racking and a 2 DOF gimble to square the Z axis to the table. With all of that retrofitting completed over the winter I'm finally back to leveling the table. Now I'm having issues with the routine. In addition, I've verified that there is a open between the plate and the table using an Ohm meter on the 2 ohm setting while there is .2-.3 ohms resistance between the touch plate and the point where the touch plate cable plugs into its receptacle on the front of the bench.  Connection is made with a banana plug and socket. I've attached my code for your review. I'm probably missing something obvious (forest and the trees syndrome).  Any suggestions would be greatly appreciated.

Kind Regards,

I have to add debounce to my sensors, too, and I don't like doing it. I tried using probing moves to move "away" from the sensors, but that's too complicated. The problem with debounce.N is that it delays the signal (it's a low pass filter). Perhaps we need a different kind of debounce? Something that reacts immediately to the first edge, then ignores further edges for a while? That would trigger on the first hit, then ignore the bouncing, trigger on the first release, then ignore that bouncing, etc. That would make probing and non-probing moves more predictable without delaying anything.

I've got both axes homing correctly though I did have to add 50 ms of debounce to all field inputs for everything to work correctly and consistently. Thanks for all your help.

Thank you for the tip.
i currently just setting up a lab/Prototyping so don't need thing to work flawlessly just enough to test things, so trying to get away cheaply witch seems a bit hard with ethercat.

so mainly IO board that you could output LinuxCNC stepper signals out of would be ideal but it seems really hard to find at least when it comes to Ethercat, if i was more versed in electronics i would probably try and develop my own Ethercat board and open source it for other experimenters.

HEY! I am so dumb I didn't see your reply till just now. I actually bought another 6i25 convinced I had an issue with the card.

ANYWAY...I don't get any errors when I launch LinuxCNC, just a hard, full computer shutdown if the 7i77 is connected to the 6i25. If the 6i25 is NOT connected to the 7i77, I just get the Linuxcnc error i posted earlier.

So...I put in the NEW 6i25 just now, hooked up the 7i77 and launched Linuxcnc...and it DIDNT CRASH this time! Exciting. Now i just get a new Linuxcnc error:

 

Looks like the firmware wants an update? Do I do this with mesaflash? 

So i just take those files and copy them in the folder of my machine?

In what way do you see 2x50k as a better way than 1x100k?
You get voltages in the 50-60V range to THCAD.

With one 100k, and recognize that ground is really close to ground on the 5V rail,
you only get a few volts in after the voltage divider.

I thought about that on my card.
 

Only what is in red has 100V (well, -100V) and thereabout, the rest is 5V max.
I made some distance between torch voltage and copper as you can see in the read.

I always excuse myself by saying I am not an electric engineer, so I can be wrong.

Regarding filter, I have a digital lowpass filter with 10 Hz pole frequency in the controller. No hardware filter.
Linuxcnc has a "lowpass" hal filter component so it can be done there also.

I used the Herocut equivalent to the Lotos. Worked fine.I live in a place where we only can have 16A, absolutely max 20A, 230V at home.
I couldn't use all the 55A, the fuse blew all the time. I replaced it with a Herocut HC8000, three phase 400V 16A. I can now max out
the plasma cutter. But the compressor need to run off the petrol generator, it's too much with that one on one phase too.

 

Edited previous post to reflect resistor values, as the drawing is just a wiring example .

I'm starting to get pissed off. This stupid Gladevcp just does not seem to want to cooperate. My two sets of radio buttons are just being stupid. There are 2 pairs with each button triggering a hal action MDI widget. Each of the Hal Action MDIs call either a small sub program or a custom M-code. A set for the left side and a right side and both are exhibiting the same behavior. I have the left unclamp radio button as the master in the left group. Pressing the left_clamp button works correctly and runs it's sub program activate the left side clamps in a sequence. I have the unclamp buttons call for a single custom M-code that releases all of the clamps at once. But when I press the unclamp button, it runs the clamp sequence, then unclamps. If I press the unclamp button(s) while the vcp screen already indicates that the radio button is in the unclamped state, then it behaves properly and only issues the unlcamp M-code.

My second problem, I also have a set of physical buttons on the other side of the machine that use Halui MDI commands to call the same sub programs and custom M-codes to clamp and unclamp. Those are working perfectly by themselves. I created some hal pins in the python call back that toggle each of the VCP radio buttons, so the screen can match and indicate the state of the clamps. If I disable eache the button's "Related Action" in glade, that all works perfectly. Pressing the clamp/unclamp buttons change the toggled buttons on the VCP like I'd like them to. But then the VCP buttons don't actually do anything. With the button's Related Actions turned on, it set up a loop, where when one of physical the buttons are pressed, the clamps start cycling on, off, on, off... continually. Well that's no good at all, but not surprising.

Any clues atll how to fix the first problem. So far everything I've tried either has no effect or stops the GladeVCP buttons from working.

I think I could work around the 2nd problem if I could fix the 1st one. I'd have the physical buttons simply trigger the glade buttons instead of calling the halui MDI commands. The other way would be to make the call back file change the active button on the VCP without activating the buttons action, but still let the button action work when pressed on the screen. But I don't know how to do that.

@  tommylight  Really interesting. Thanks.

I've added the SPI isolation. The whole thing is now fully isolated.

 

edit:
The values are placeholders, i usually use 2x470K to 2x1M for the side resistors and adjust the value for the middle one depending on what i can find.

I use the filter for a couple of reasons:
1. environmental noise
2. I don't trust cheap plasma cutters to output clean DC

I see a couple of capacitors and resistors as cheap insurance against potential future problems.

I want to be able to confidently support cheaper options like Lotos LTP5500CNC. That's the one I have. It works fine and is a small fraction the price of a Hypertherm.

I actually looked at supporting HF start machines in the past. I just couldn't justify the cost and effort.

Anything is possible, I just need to think about the best way to implement that.

Just about finished a massive update on control enable/disable so the dust needs to settle a bit on that.

JT