Advanced Search

No worries, just trying to prevent you wasting time and wondering "why it does not work" if you make the same typo where it actually matters.

PCW wrote:

One advantage of the MPG encoders over the normal high speed encoders
is that the MPG encoders support the 1X mode, which means you get one increment
per click on standard 100 PPR MPG dials.
 

One advantage of the 1X mode is lack of direction information...
Standard encoders have no clicks...
In mpg encoder's count is scaled and can be divided by four... 
 

Ah, sorry, it was late. Of course, I mean "LOG_LEVEL = 0".

During cutting or at idle?
-
If during cutting, check grounding, if it is shallow under ground, the ground getting dry will cause that.
If at idle, there are a lot of things that can cause that, like other machines in the shop, changing the power socket, stepping on the wiring, wiring isolation failing somewhere due to fatigue and/or strain, and if in Europe, even your neighbor installing a new air condition unit, etc etc.
A simple solution to remedy the latter, use a 0.01 to 0.022 uF (also known as 100-220nF) capacitor on the THCAD input.
I use a 0.1uF electrolytic one rated for 50V but that might lower the reading speed, although for me it works perfectly fast till 6m/m, i have not tested it faster.

Hey when i first built my table my thc would read only + or - 1-2 volts over time its gotten worse and worse now it reads + or - 8 volts or so. Any idea whats causing this? Its running off raw arc voltage with a bunch of resistors in series. 

Thank you for your reply. Currently, my kinematics has coordinate offsets of (Xrc+Xos, Yrc+Yos, Zrc+Zos) when A=0, C=0. As you mentioned, "the coordinate values ​​remain consistent when switching between simple kinematics and RTCP kinematics." Therefore, it's certain that my kinematics might have a problem. I also have a few questions:

1. Is it necessary to use the tool tip coordinate system as the basis for deriving the kinematics?

2. I noticed an article on kinematics derivation, which I've attached. After deriving my machine tool kinematics using it as a standard, can I directly replace the XYZAC kinematics code in my code? Or do I need to do something else?

I will immediately put these two questions into practice.

Looking forward to your reply.

boink.
I think everything works now. got help with the correct updates on the ethercat patches/version. I geared down the 4th axis, so it can do 1600 turns now. not a proper fix, but it will get me cutting today and we can figure out a more correct rollover later.

As always, thanks for all the help.

Looks interesting! I'm always keen to see new UIs being built.

My only comment is regarding your implementation of what you are calling 'macros'. I assume these are different than calling o-call macros or python-based macros. Just remember that the modal nature of gcode/LinuxCNC makes all macros trickier than it seems at first.

5_Zylinder wrote:

I did, however, forget to add the "TOP_LEVEL = 0" command. I'll add that now.

That was not mentioned anywhere, so why?

Aciera wrote:

PATH_PREPEND= ./python
PATH_APPEND= /home/cnc/linuxcnc/nc_files/remap_lib/python-stdglue
TOPLEVEL= ./python/toplevel.py
LOG_LEVEL = 0 


 

A 160V DC bus supply can only provide about 110 VAC to the motor
so you would be limited to about 1/2 the servo motors full speed.

We tried your suggestion, and the error message "G-Code error in axis.ngc" is now gone.

I did, however, forget to add the "TOP_LEVEL = 0" command. I'll add that now.

I wanted to execute the command "o<toolchange> call" in MDI mode. However, I received an error message referencing the tool change program sequence: "Named parameter #<tool_in_spindle> not defined." It seems to me that this parameter hasn't been declared yet, so the system can't locate it.

Perhaps you have a solution for this problem.

Hello all, I’ve been struggling for about two weeks to flash a bitstream onto my Colorlight board (V8.2) using an external Adafruit FT232H USB-to-GPIO/SPI/I2C board, but I keep running into JTAG initialization and IDCODE errors.

I'm hoping someone here might spot what I am missing in my setup. Here are the details of my configuration and what I've observed so far:

• FT232H D0(TCK) - Colorlight TCK J27
• FT232H D1(TDI) - Colorlight TDI J32
• FT232H D2(TDO) - Colorlight TDO J30
• FT232H D3(TMS) - Colorlight TMS J31
• GND - Colorlight J34 (3V3 is not connected)

The Problem: When running openFPGALoader, the tool successfully communicates with the FT232H, but the JTAG initialization fails because it reads erratic, shifting IDCODEs (e.g., 0xfffffffd, 0xffffffe1, 0xfff11043, or random bit patterns) instead of the expected ECP5 IDCODE. Note: If I try to supply an external 3.3V to the VCORE pin of the FT232H, openFPGALoader immediately throws an Error: no device found. Leaving it unpowered/floating lets the FT232H enumerate, but yields unstable JTAG reads.

Commands:

Questions: 
Has anyone successfully used an Adafruit FT232H to flash a Colorlight V8.2 board via JTAG?
To completely rule out any issues with my current .bit file (or potential synthesis/mapping mismatches), does anyone happen to have a known-working, minimal test bitstream (e.g., a simple blinky for the ECP5 LFE5U-25F / Colorlight 5A-75B) that I could use just to verify that the flash programming and execution works?Any advice or working command configurations would be greatly appreciated!
Thanks

If you had signed PWM hardware and you got minus full scale
instead of full scale with a full scale positive PWM value, then  yes,
inverting the PWM scale would fix the problem.

For unsigned PWM when 0% duty cycle PWM gives you full scale output
and 100% duty cycle gives you 0% output, you would need to digitally invert
the PWM pin (and this is the situation here AFAICT)
 

Yes, the 7I97/7I97T have 8 dedicated MPG pins on the isolated inputs  (inputs 0 ..7)

The four MPG counter names are:

hm2_7i97.0.inmux.00.enc0-count
hm2_7i97.0.inmux.00.enc1-count
hm2_7i97.0.inmux.00.enc2-count
hm2_7i97.0.inmux.00.enc3-count

One advantage of the MPG encoders over the normal high speed encoders
is that the MPG encoders support the 1X mode, which means you get one increment
per click on standard 100 PPR MPG dials.

There is also a good MPG example in the docs except in Mesa land, you don't use the encoder component
linuxcnc.org/docs/stable/html/examples/mpg.html
Not sure on the 7i97 but there are some dedicated MPG pins on the Mesa 7i76e (and for the 7i96 if you use the right bit file and give up some pins.