Advanced Search

You need an up-to-date version of mesaflash

github.com/LinuxCNC/mesaflash

(Build instructions at bottom of page)

The fact it runs in AXIS means the program is ok - that's good.
If the user system is not set quite right it won't run in AXIS or QtDragon.

If any of the motion commands move outside the red boundary box, you will get this error.
Hard to tell from this angle.
Are any of the plot lines outside the red boundary box? This includes rapid points.
Does the machine move at all? i wonder it it's actually the tool change.
Sometimes linuxcnc lies about what number the problem line is.

Chris

The inmux has a different module ID section entry:

package PIN_SV8_7I36x2D_72 is
    constant ModuleID : ModuleIDType :=(
        (HM2DPLLTag,        x"00",    ClockLowTag,    x"01",    HM2DPLLBaseRateAddr&PadT,    HM2DPLLNumRegs,            x"00",    HM2DPLLMPBitMask),
        (WatchDogTag,        x"00",    ClockLowTag,    x"01",    WatchDogTimeAddr&PadT,        WatchDogNumRegs,        x"00",    WatchDogMPBitMask),
        (IOPortTag,            x"00",    ClockLowTag,    x"03",    PortAddr&PadT,                IOPortNumRegs,            x"00",    IOPortMPBitMask),
        (InMuxTag,            x"00",    ClockLowTag,    x"02",    InMuxControlAddr&PadT,        InMuxNumRegs,            x"00",    InmuxMPBitMask),
        (MuxedQcountTag,    MQCRev,    ClockLowTag,    x"08",    MuxedQcounterAddr&PadT,        MuxedQCounterNumRegs,    x"00",    MuxedQCounterMPBitMask),
        (MuxedQCountSelTag,    x"00",    ClockLowTag,    x"01",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (PWMTag,            x"01",    ClockHighTag,    x"08",    PWMValAddr&PadT,            PWMNumRegs,                x"00",    PWMMPBitMask),
          (SSerialTag,        x"00",  ClockLowTag,    x"01",  SSerialCommandAddr&PadT,    SSerialNumRegs,         x"10",  SSerialMPBitMask),
        (LEDTag,            x"00",    ClockLowTag,    x"01",    LEDAddr&PadT,                LEDNumRegs,                x"00",    LEDMPBitMask),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (NullTag,            x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000000"),
        (InMuxWidth0Tag,    x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000020"), -- hide this tag here until we find a better way
        (InMuxWidth1Tag,    x"00",    NullTag,        x"00",    NullAddr&PadT,                x"00",                    x"00",    x"00000020") -- hide this tag here until we find a better way
        );

Note that this example uses 2 inmux interfaces both with a width of 32 (0x20)
 

FlaredFins wrote:

I don't think i have my Z set correctly no issues in cutting or height control, When the machine is homed for the first program run, it runs up to the Z+ Prox / Z home from their it drops down to I'm guessing an offset I put in. it than drops down about 2 inches and zeros the Z drive. not a big deal but when I'm trying to line the torch up it won't go below 0.00 is it better to let the Z axis home off the probe or an upper limit.

Some info on the Z axis:
linuxcnc.org/docs/devel/html/plasma/qtpl...plasma:initial-setup
 

On Probe it does this weird little double probe you can watch it come off the probe switch than go back to it than proceeds to cut height. is this normal or am I missing something in the settings?

The two most common reasons for this are:

1. The Probe Height is set too high compared to Safe Height.
2. Probe Height is set below the material height and the first probe trip is done at Setup Speed then the second trip is done at Probe Speed.

During that no arc ok phase I also noticed that QTPlasmac will attempt three times to fire the torch after the third round of that it powers off with the screen switch and resets the program. Is this normal if it is, is there a way to change the number of rounds it will go through before resetting the whole program.

Not sure what you mean by resetting, the program should go into pause mode after the failed attempts.

linuxcnc.org/docs/devel/html/plasma/qtpl...lasma:parameters-tab

Yes, the board has multiplexers. . I have to use inmuх.
Before adding the shared encoder index pulse . The board was working. I will try to compile the firmware with last line included.
(InMWidth0Tag, x"00", NullTag, x"00", NullAddr&PadT, x"00", x"00", x"0x00000b")
Yes, this line is missing in the examples I looked at .
There are 24 inputs pin on the board .On mesa the board uses 6 pins (5 outputs and 1 input)
For x"0x00000b" I have to put the number 18 .
thank you very much for the help

spumco wrote:

Was there something wrong with the U3K and BLDC? Or are you just sick of fiddling and want a drop-in solution?

If so, there may be better - or at least other - options than the DYN4 and 750w servo.

I was ripped off on the U3K the guy wont reply to my messages wont refund it and it has errors 'Fault errors' that wont clear out when I click the clear errors in Ultraware. Then I went looking for another one and they are all over priced. But yes im looking at another option with the AC servo. Pluss if I take the hall sensor off that BLDC im pretty sure ill never get it back on timing with the motors windings. If I just go this rout I can still have a simi functioning machine incase im too dumb to learn how all these motor signals and stuff work with encoders and LinuxCNC configuration.

Other wise no I am still checking the used U3K market every day and will get another one then convert that BLDC because I've gotten so far till the rip off occurred. Its just frustrating I spent weeks to discover that the drive is bad. But thanks im just impatient with the used U3K's rite now 


What other options do you recommend? I know we've been over this before and btw I really appreciate your helping me out with this but what options do you know of? Id like to if at all possible at least have the same shaft and fram size motor. I don't really care if i have to flip the thing upside down just something that doesn't involve sophisticated bracket manufacturing lol

I just ran the exact same file in Axis with no issues.

Additionally, I commented that line out, ran it from QTDragon and it still gave me the same error.

Still learning how to reply using quotes on here sorry

Yes, The electronic board says 7i96s. When purchasing, the 7i96s was chosen. The board layout is from 7i96s.
Is there any jumper or configuration to enable the card update, perhaps some necessary operating system permission procedure? I'm using LinuxCNC 2.8.4

Thanks for the script! Had been fighting this issue for a few days with errors talking to a mesa board on a N100 that I was setting up. Worked great on once I fixed the same issue Swag had.  My static IP had been 10.10.10.11.  Changed it to 10.10.10.1 and the ping to 10.10.10.10 was good, previously I was getting random 3ms spikes.

ping 10.10.10.10 -i .02
...
325 packets transmitted, 325 received, 0% packet loss, time 8151ms
rtt min/avg/max/mdev = 0.080/0.101/0.127/0.007 ms

 

Still learning how to reply using quotes on here sorry

Was there something wrong with the U3K and BLDC? Or are you just sick of fiddling and want a drop-in solution?

If so, there may be better - or at least other - options than the DYN4 and 750w servo.

The strobe pin serves to indicate that the position of each tool is valid, this pin on the carousel enables the carousel pin. ready and serves, for example, to stop the rotation of the motor. The pin of the pre index control proximity sensor is used to activate the pre index solenoid, which must be activated when the pre index sensor signal is activated. I don't know what the exact model of your turret is. I have a TOE 100 turret that is very similar to yours. The diagram that I publish is blurry and cannot be seen well.

Ok thanks, I do plan on connecting the encoder data to the Mesa as well if i go this route. I'm just wondering if its ok to do what I'm trying with this motor and having it spin 3000k rpm for hours? That and if these components will even work together and how to configure it all. If Its getting feedback can I still use analog?

hardware-irq-coalesce-rx-usecs 0 this line right here?