Advanced Search

Got some time to review mill operation.
Delving into G54 and G55 Offsets.

I think my problem was an attempt to travel beyond the Z- soft limit.

So, one of my current educational tasks is to try and get something like an error code displayed on a soft limit excursion.
As suggested, like HalScope or HalShow.

Ping times look super other than the glitch, also on the latency test.

Could it be a glitch in 6.13.

SI = Signal Integrity (fussiest signal would be the clock)

I'll look into the power supply.

SI = serial input ?

Thanks again.

That's the main file and forgot to attach it! Here it is Andy.
-edit: Attached the latest test remap that I haven't tried yet. Original attached.

Maybe some power or SI issue at the Flash EEPROM?

The firmware has a 5 ms timeout for page writes (3 ms max on the W25Q16)
The erase timeout is 3 seconds (400 ms max on the W25Q16)
so that should not be an issue.

I was reading the qr_auto_probe_tool.ngc code and this line:

#<calculated_offset> = [#<touch_result> - #<_hal[qtversaprobe.probeheight]> + #<_hal[qtversaprobe.blockheight]>]

Appears that the tool length, #<calculated_offset>, should equal the distance between the probe length and the loaded tool length. It is saved using

G10 L1 P#<tool> Z[#<calculated_offset>]

Which would indicate the length of the tool "should" be the difference between the probe length and the loaded tool length. We can assume the #<youch_result> as zero if we reprobe the probe...I think.

However, I get -70.(Something) For my probe length and -90.(something) For my tool length when the tool is shorter than the probe. At least in the tool table.

I think it would work better if the probe touched off and then, instead of "work piece height" which may or may not be G5? Z0, we should just be instructed to probe the Z0 point and set the offset between the tool setter and Z0 as a constant. Then just add that offset to the probe height and be done with it.

I believe the coding to include block height in every calculation is unnecessary and can cause errors. Plus, and I realize it's not Python, but the code could be more readable if there was a single constant offset then just amending the new tool length by that offset.

I may well be way off base here, because I am new and the code is different than what I am used to. But, I think the height setting could be simplified a bit. Just my opinion. Not trying to step on anyone's toes because it's obvious they put a lot of work into it already.

Ran
./mesaflash --device 7i92 --addr 10.10.10.10 --verify ~/linuxcnc/firmware/7i92/TopEthernetHostMot2.bit

about 10 times passed every time.

Just for completeness tried verifying against another bitfile (not written to flash) and failed as expected.

Hold & WP are tied directly to 3.3v CS is tied hi via 10k resistor.

If the main clk is out, part is marked as 50Mhz, could this throw a spanner in the works ? But then that would affect the Ethernet Interface's 25Mhz clock.

It feels like the write is taking longer than expected, but checking the busy flag would mitigate this. That's why I thought of putting a delay between mesaflash wiritng a page and the "packet read for board syncing"

Thanks a lot!
If someone need it the code is: 
rtapi_module_param

D

This helps..
What is OUTPUT_SCALE = -10800 ?
This config is for fixed motor:spindle transmition ratio.
I have 2 selectable speeds after encoder-motor
These 2 speeds are selected by hydraulic electrovalve that switches gears
position 1 max rpm is 760rpm and position 2 max rpm 3060

How to do it with only 1 button that has function cycle start / pause / resume ?

Hold on a second. I lied. Not intentionally. My spindle motor is a DYN4 servo motor geared 1:1.8 and it has a simulated encoder signal generated by the servo driver. That is the signal I am using for the coordination for rigid tapping. The sensor on the slotted plate it just for measuring RPM.
It's been a few years since I set this up and when you mentioned more slots I thought "I knew that, why didn't I do that?" Then I looked deeper and remembered how it really works.

To actually do this with a slotted plate and sensors you would want more slots and two sensors. Read up on how quadrature encoders work.

As long as you know the ratio between the spindle and encoder you can make almost any arrangement work.

These are my .ini settings.
[SPINDLE_0]
P = 2.0
I = 4.0
D = 0.0
FF0 = 1.08
FF1 = 0.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
OUTPUT_MIN_LIMIT = -5400.0
OUTPUT_MAX_LIMIT = 5400.0
OUTPUT_SCALE = -10800
ENCODER_SCALE = 4551.111111
#((2048 * 4) / 1.8) = 4551.111111
#The maximum spindle speed (in rpm)
MAX_FORWARD_VELOCITY = 5400
#The minimum spindle speed (in rpm)
MIN_FORWARD_VELOCITY = 50
#This setting will default to MAX_FORWARD_VELOCITY if omitted.
MAX_REVERSE_VELOCITY = 5400
#The minimum spindle speed (in rpm)default to MIN_FORWARD_VELOCITY if omitted.
MIN_REVERSE_VELOCITY = 50

Sorry for the confusion. I hope this helps.

The pulley ratio is 3:1

Why would it be 3.2:1?

60:20 = 3:1

I think the driver is just busted.

60:20 = 3:1

600 is correct.

Does the motor buzz or move differently with 1600 steps/rev vs. 200 steps/rev?

Good thing drivers are insanely inexpensive these days.

Can it verify repeatedly without error?
If so if may be something related to write
(how are the WP and HOLD pins terminated?)