Advanced Search

Yes, 000000 Indicates the likely U3 has been damaged and is shorting out
the shared 4V supply so U20 and P2 will not work either.

I'm surprised that there is no SMT repair facility available there. We routinely repair
minor faults like this for a nominal fee ($35.00), but of course shipping is s killer.
(the part is about $1.00)
 
EDIT:
Its likely that if you simply removed U3, that the other port would work allowing
you to connect the 7I85 to P2.

The 0x1004 is simply the register address of the GPIO port that's connected  to P1.
It should be all ones = 0x0001FFFF when unconnected because the expansion
GPIO ports on a 7I76E have pullup resistors and all GPIO is set to input mode
at power up or watchdog fault. All 7I76E firmware is open source and the low level register
addresses/functions are provided in the regmap file in the source directory of the 7I76E
software support zip file.


The 7I76EU is a one-to-one replacement of the 7I76E, no hal file changes are needed,
unless you want to use one of the new features.

If linuxcnc.stat call_level is 1, the preview in flexgui is disabled, and i try to find a way to solve that, but i have no idea what to change in stdglue.py.
 

Maybe that is actually a bug in flexgui?
If I start the example program in

`/configs/sim/axis/remap/rack-toolchange/racktoolchange.ini `

I can see the call_level staying at '1' until the whole program has executed but the preview works just fine:


 

cool

1: you mean a mbus_device template ? yes i will check it

2: Do you mean the Modbus outputs? Yes, there is something there, but I’ll need to check it again as I’ve rewritten the Modbus plugins. (Error values)
Basically, it’s just the Modbus message but without the address and without the CSUM.
This is then sent when the FPGA detects an error (disconnect / timeout).

I'd like to share some latest information regarding current status of the project.
Support of serial port (with almost the same principle as pktuart) has been added in last pull request. Yet not approved by Peter. github.com/Peter-van-Tol/LiteX-CNC/pull/155

Thanks @meister , now works! 
Two more things:
-1: would be grateful if we could make a preconfig for that kind of board.

-2: In case of host disconnection...Can I force a value?. For example, if some of the signals are high, if I close the Linuxcnc, I want to force all signals low.

 Thank you.

In my setup is a problem with stdglue.py, the version provided with linuxcnc. In my case, it's a remaped M6 (REMAP=M6  modalgroup=6 prolog=change_prolog ngc=change epilog=change_epilog), in terminal is printed 'emcTaskPlanLevel() returned 1' , linuxcnc.stat call_level returns 1 as well. It returns 1, until the final toolchange is done and then the returned value is 0.
If linuxcnc.stat call_level is 1, the preview in flexgui is disabled, and i try to find a way to solve that, but i have no idea what to change in stdglue.py.
If M6 is done without remap, everything works as expected.
 

Actually, it could be a regular wifi scan. Try this to disable it and report back.Add this text and save
then type

This is more likely due to a Linux service firing regularly rather than being ethercat related.
What Operating system and kernel version.
What steps have you taken to tune your kernel?
 

Thanks a lot for the fast response PCW

Both comands returned 00000000 (when lncnc is running in the background, the operation is not permitted,right?).
I take it, this means there is no response, or a faulty one. Now I can see some slight color degradation on top of U3 compared to U20, which i brushed off as dirt before. But it`s probably from the accident.

Is there anything else to test before trashing it? I don`t think anyone in Switzerland is doing PCB repairs, and if they do, a new one is probably cheaper.
Since the 7i76 is replaced by the 7i76eu, I will have to get the new one (if it`s even available atm). Is there any major change between them, or can I more or less leave the .hal file as is? I probably have to change the name everywhere, but as far as I know, the rest should be working the same way.

Thanks again for your help. I see your profile on every second post on this site and it helped me countless times before. I appreciate you taking the time to support so many people.

P.s. Is this "rpo 0x1004" something one should know, or is this more of a manufacturer inside knowledge?

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