Advanced Search

Possible to embed in AXIS:
 

You can do a quick check of the expansion port condition with:

mesaflash --device ethernet --addr IP --rpo 0x1004
for P1
and:
mesaflash --device ethernet --addr IP --rpo 0x1008
for P2

Where IP is 10.10.10.10 or 192.168.1.121 depending on 7I76E setup

Both should respond with  0001FFFF (with nothing connected)

Typically what would be damaged from this kind of a fault would
be either U3 (P1) or U20 (P2) = 74CBT16211CDGGR

P1 (U3) damage may show up on P2  (U20) as the chips share a low current
4 V power supply and a damaged chip may short this supply so the undamaged
one also shows a fault.

Hi everyone,I’m persisting in my efforts to get my machine finished using various methods.We’ve been trying to work with `carousel.comp`, but we’re running into issues with positioning the carousel. The cam limit switch is connected to Pin 28; it indicates the home position and is wired as Normally Open (NO). Pin 12 is connected to the proximity switch used for positioning the drive motor. It’s an NPN sensor: the contact is inactive when the cutout (missing material) passes by, and the sensor activates when material is present. Image 2 shows the program sequence as displayed in the screenshot. The problem arises when the cam limit switch (Pin 28) is triggered: the motor shuts off, but the carousel ends up positioned between two pockets. The motor needs to rotate another 180° so that the cutout aligns with the sensor. Image 1 shows the correct position—with the cutout aligned to the sensor (Pin 12)—even though the limit switch (Pin 28) has already been cleared.Can anyone suggest a solution for getting the positioning right?We’ve tried using "NOT" commands within `carousel.comp`, tried to wired as NC but haven't been able to resolve this specific issue.

Hi Guys

I am currently building my first Linuxcnc powered milling machine and the problem i`m facing now led to the first forum post in my life.
I use a Mesa 7i76e and added a 7i85 for the encoders. A while ago, I have set up all the servomotors and could even get them to run with the encoder feedback (encoders only update the DRO for when i want to mill by hand, without the motors). 
Unfortunately, a live wire touched one of the two boards and a bit of magic smoke got released. I didn`t see where the smoke emerged and i don`t see any damage on either board (but the amount of smoke should indicate some visible marks). Now my Encoder counts don`t get recognized by the Mesa cards. This is my current situation:

- I watched halshow and neither rawcounts nor any other counters see anything. 
- The encoder on the 7i76e still counts correct. This let me believe, that the encoders and wiring are good.
- The .hal file should be of no concern to me, correct? Halshow shows all 5 encoders but only Enc04 on the 7i76e counts.
- I bought a new 7i85s (7i85 were not available) and the new card doesn`t count either. (I flashed the correct bitfile)
- I put the 7i85 as well as the new 7i85s on the second expansion port and neither of them counted. (I flashed the correct bitfile)
- I tried to use one of the stepgens on the 7i85s but got nothing. (Tough, this one could be on me with a wrong configuration)
- I unfortunately don`t have another ribbon cable at hand. Is it possible, that the cable got damaged? I doubt it.
- The jumpers on both cards should be set correct (to RS422, power supply via exp port) and haven`t been changed since it worked in the beginning.

My question: Is it possible to force a sign of live out of the 7i85? Or somehow get proof, that the card gets "recognized" by the 7i76e? I would like to avoid unnecessarily buying a new 7i76 since they are hard to get and pretty expensive. Can I test something with a multimeter?

I`m grateful for any thoughts or ideas. However, my knowledge about electrical circuits is pretty shallow and even worse around software stuff (I hate Linux with a passion even tough I love the idea of an alternative to Microslop).

Thanks and greetings from Switzerland

P.s. I saw another post and it seems there is a terminal comand where you can force some response or a dump of specific components on the card. But I really didn`t understand anything going on.

Hello,I am updating my test environment to the latest software version.I noticed that the noise issues occur roughly every 36 seconds. 

Attached is the Halscope log.

Thanks for the write-up and the machine tests. I am not a G71 expert either, so take this as “what I changed”, not gospel.

I am targeting native LinuxCNC 2.9** only (`G71 Q… D… I… R…`). In those docs, D is remaining distance to the profile (finish stock) and I is the cutting increment** (DOC). PathPilot uses a different letter set, so the two will not match; this tool follows the 2.9 page, not PathPilot.

On G7: I do not think diameter mode should halve D/I/R. In my view DOC is still DOC in G7 or G8 — the rest is just a display issue. Logical in my view is that depth of cut reduces diameter by DOC*2. G71’s increment is radius-based as well. Treating G7 as “divide the cycle words by two” also dragged in a lot of other mistakes (G72, retract, mixed scaling). I am not taking that path unless someone can convince me this is the way to go.

v1.1.0 is out with:

- G71/G72 letters swapped to that 2.9 meaning (UI labels too: DOC is I, stock left is D).
- L-shaped rapids instead of a diagonal `G0 X… Z…`.
- An explicit retract between G71/G72 and G70, so finish should not cut a corner through stock.
- Start/retract X now includes G2/G3 bulge past the endpoints, not just min/max of the points.
- Retract X is separate from a user Start X (so a bore start is not used as the pull-out).

I did not adopt G7 `/2` on D/I/R, cutter comp, or “finish only, skip G71”.

I have not had time to run this on a real machine yet, so treat it as untested on iron. Dry-run / sim first. If someone who lives on native 2.9 `G71 Q` can sanity-check the D/I mapping, that would be very welcome.

Profiler 1.1 is here

Just took a look at your drive manual, and it's... really sparse.

I don't know of anything in lcec or cia402 that constantly polls the drive(s) for communication status, but I had an idea that might be worth exploring...

What I was thinking is to use one of the drive's digital outputs as a tattle-tale.  It's not clear in the manual if the DOs reset on loss of communication, but on my Stepperonline A6's that's an option only found in the tuning software.

I can program my drives' digital outputs to either retain the last state or turn off if communication is lost.

If you can set yours to turn off, then you could create DO hal pins in xml file.  Those pins are then turned on in HAL whenever LCNC is running.  The DO is then connected to an LCNC input - a DI on a different drive or other Ethercat slave device.  That input is connected to motion.external-fault-NN - and it all acts like a drive communication estop.

If the drive is unplugged, the DO turns off... then input then turns off, which triggers an external fault in LCNC.

It all depends if you can set the outputs to non-latching in the drive tuning software and you have a spare input somewhere.

Reminds me I need to test my own system for an Ethercat cable failure.

I hope I’ve managed it now; it’s a bit tricky without the hardware

please set back to 16 values, update dev and try again

oh, no, my fault, i send number of bytes, not number of registers

i think the problem is, your device returns 4 bytes, not the requested 2 ?!?!



you need to pull dev to incrase the values, with my simulation it works, but it's a workaround,
i will write a fix, to read the values in the right order and ignore the last 16bit's

You can use mesaflash's --readhmid option to show the TB3 MPG encoder pinout:


 

I ran a couple of tests, and the raw Modbus data makes sense. The board's response is OK, and the data corresponds to the DIs that are ON.
Seems that the mistake is in the LinuxCNC HAL config.

IN1
> MODBUS_TX(mbus0): 1 3 0 192 0 2 196 55
 MODBUS_RXmbus0: 1 3 4 0 1 0 0 171 243

IN2
> MODBUS_TX(mbus0): 1 3 0 192 0 2 196 55
 MODBUS_RXmbus0: 1 3 4 0 2 0 0 91 243

IN1 + IN2
>MODBUS_TX(mbus0): 1 3 0 192 0 2 196 55
 MODBUS_RXmbus0: 1 3 4 0 3 0 0 10 51

new dev update:

go to mbus plugin-config and set the new debug flag

hope that help's

Hi Meister, I updated to the dev branch, but I don't see any difference. Is there any way to sniff the Modbus network?

@Oxbown please try dev branch, i hope it works now, have no hardware to test.
and please set the Register address to 192.