Advanced Search

I may not be asking the right question. Is there a way to ensure that when the estop is pressed or a limit switch is triggered, to tell the torch to come off and not come back on?

I thought maybe by editing the M3 g-code, I could get it to work for my machine and also get the estop and limits to turn off the torch.

Is there any way to link the output pin 00 to the estop and limits, in such a way that it wont turn back on even when the machine is reset, and stay off until it gets a new command to turn on?

My next idea is to make my own M code that has my needs in it, but i feel that i will still run into the same issues where the estop either doesnt turn off the torch, or if it does, the machine "remembers" it was firing and immediately arc.

One thing to look out for in Mesa's design of the 7i92 fet bus switches were used for translation between 3.3 to 5v. I think I can recall PCW saying that they were never intended to drive any loads directly but through at the least a buffer or more likely through a breakout board.
Another thing is, if the vendor has changed any pin assignments and have not provided a ucf file the only way to find out pin assignments would be via JTAG, the easier method of via direct probing of pins, which isn't a lot of fun with the pin spacing of the FPGA. Not knowing the in assignments would make modifying the firmware somewhat difficult at best.

So there could be some gotchas for new players.

Currently working on a machine using the QTPlasmaC GUI, and I was wondering if there was any way to access the M03 sub routine file anywhere? I would like to edit it to disable the homing of the Z-axis that it does. 

Right now the machine fires the torch using a regular output pin, which works fine when everything is going perfectly, but when a limit is triggered or the E-stop is pressed, it doesn't quite understand that it needs to disable the torch as well. 

I was able to almost work around this by messing with the hal file and using an and function to turn off the the torch when the e-stop is pressed, but the problem is when the machine is reset it has a memory of last being told to turn on, and so the torch fires.

My thinking is that if I can go in and mess with the M03 instructions I can just completely disable the Z-homing because all of this has been a work around for that, because my machine has no z-axis. 

Thanks!

By what metric have you been testing latency ? Your process and figures would be interesting to see.

The other thing that would be a major obstacle is that there is no real time kernel for BSD in the way that there is for Linux. Syscalls maybe another issue as well, I'm unsure whether the APIs for BSD and Linux are the same.

Linuxcnc isn't "designed for debian" originally the ISO were built for Ubuntu, but licensing became an issue. Linuxcnc can be built for any distro. Years ago I was running Linuxcnc on Slackware and in a moment of pure madness I built it on a system built using the LFS & BLFS way.

As for "stupid back ground processes" it's up to the user what they want to run in the background and what features they want to lose. Do you want the OS to mount a drive when plugged in or do you want to mount & umount the drive manually ? What processes do you sugeest turning off for the best system ?

I have a choice of 12 items, and tried the Qcombobox. I was able to populate it, but it seems its not integrated to get the selected item for further processing. I used radiobuttons for a choice of 2 or 3, but for this amount of selections the switchboard is getting too big. Am i doing wrong, or is this not part of flexgui yet?

 

Do you get any motion now?

There was a build for ARCH Linux a while back, but i do not recall any BSD option, although you can always try building from sources.

What version is your installation now?

You can try 2.9.4 if you like.

The Desktop Environment and OS as a whole are probably a bit more polished.

Old XFCE was pretty ugly.

It's Alive!
I reverted back to my old installation and succeeded in clearing all errors except the kinematicsSwitch error.
I then tried a basic config in PnCConf and it worked. (I did not know PnCConf existed)
I am now reading a MPG in halscope, and am confident that by hook or by crook, this mill will run before the year is out.
Thanks to all for the help so far.
#happyChappie

You can setup gantry machines with pncconf:

 

Been trying to get the estop and machine on circuits working properly today with help from marks mh400e information which he kindly sent to me. 
just wondering if the older mahos have the same estop chains and components?
 

Thank you so much for pointing me in the right direction. 

Yes, any AI I asked eventually started hallucinating code that broke things. 

I did have someone send me a template HAL & INI set for the machine I am using (a Platform CNC with upgraded linear rails. Excellent hardware, currently being let down by confusing software, and its operator.) I was able to cobble something together that mostly worked, after much iteration. Since this was done manually, it didn't help me with learning and using PnCConf, which I would prefer. 

At this point I have everything moving, but until I sort out homing, the Y & Y2 axes are not moving in unison. They are seen as separate Joints 1 & 2. I assumed there would be some way to simply lock them together as one gantry joint(?), but apparently that's not how LinuxCNC works.

Yes, I have flashed the G540 firmware to the 7i92 card.

Can you post a picture of the actual board.

(A picture you took)

Pictures on aliexpress are not known for being trustworthy, though sometimes they actually are.