Advanced Search

This looks great. Thanks for your work!

I will probably use it for IO and rotary encoder counting for my control panel (servos are ethercat).
Rotary encoders for MPG / feed override / spindle override.

ok great.

I don't see any smoking gun.
Can you test the simulated auto tool config to see if it does the same thing?
You simulate the probe with the on screen button (when the label says probe)

Sounds like you have some electrical noise or maybe need to add some debounce. Remove slow feed by changing to 0.0 and just try using fast feed rate. If you move to slow probes can sometimes double trigger which cause issue. It's best to use a bit more speed. As long as you calibrate at the speed you probe at, you should retain consistent repeatable results

good afternoon!
today I played around with MesaCT for the first time, and I saw that the generated configuration (for my 7i76eu) has a different naming / nomenclature for my outputs than pncconf...

pncconf outputs lines like this:
net dust-removal-out motion.digital-out-03 => hm2_7i76e.0.7i76.0.0.output-03

while mesact creates these lines:
net flood-output iocontrol.0.coolant-flood => hm2_7i76e.0.gpio.031.out

where does this "gpio" come from? is this redundant or did I do something wrong in the tool?

regards!

I have had probing working for a bit and its been solid.  But today I had a strange event happen, not sure if it was me or something else.  I don't believe the settings are different than before.  Not sure what to even check.

I was probing Z only, and things started fine, the probe was going at the slower rate, tripped, then instead of backing off (Z+) it continued at the fast feed rate (Z-).  Another ruby tip smashed.

I tried again, and it did the same thing.  For a third test, I jogged x-y away from the part, and also jog z+, and tried on a "test" part (just a flat pen held off), and it worked fine, and now it seems to work fine.

What would cause a probe cycle to continue vs backing off?  Or did I make some mistake.  Either way, I want to avoid this again... probe tips are expensive.

Thanks! I should have been able to figure that out. I went deep into a deep dark hole. Sorry, I missed the obvious. Again Thanks!

Probe z in the fixture, then mount your part, select probe position only, probe corner, then zero x and y.

Probe only proves and finds the corner without setting a new work offset. But will be positioned over the corner.

I have a part that I need to probe.  The Z is from the bottom of the part, as the thickness is very important.  So I want to probe Z prior to probing the edges (corner) of the part as the part will cover the Z (top of fixture /bottom of part).  I know I can do the corner first, remove the part then probe z, but that requires to put the part back in the same X-Y postion.

Thanks

 

After a long time I managed to compile Remora for the cloud, but it does not enable the emergency button, I believe the manufacturing is correct, the ping is 10.10.10.10, I read a little and saw that I had to play the .tx file to the cloud, it gives a timeout warning for error traffic and does not play the file, reading a little more I saw that there is a short window to be able to play this file, I tried several times to turn it off and try to play the file as soon as it is turned on and reconnected, but without success, can someone help me?

YAYYYYY
Got the Ryzen 7 7700 for 215 Euro, ASRock B650M-HDV/M.2 mainboard for 120, and ... drum roll please 96GB of DDR5 5200 RAM for 146 Euro!!!
Put together two nights ago, finally mounted the Arctic water cooler to CPU and .... could not plug the RGB connector for over 15 minutes! Dang it, to small holes on the plug so i will have to dig some 0.8mm drill bits i have somewhere in the shop to fix that, i like that devilish red glow it looks like the fire monster from Lord Of The Rings movie.
Now, i have an Intel 14400 for sale...
More pictures, after i plug the RGB and mount the tempered window.

vre wrote:

How you will implement this because
raster engraving with mesa not supported to linuxcnc.

That is not correct, i use LinuxCNC with and without Mesa for engraving and it works perfectly.
forum.linuxcnc.org/show-your-stuff/46752...ver-etcher-scratcher
Configs should be attached there, and yes, it is the same thing as laser, it uses PWM for pressure control.

Hi, 

after a few month working with my bread board set up, I am continuing to build up a PCB board. The pin connection is currently all over the place, but it works... I am cleaning that up and have a quick question about the Tang Nano 9k. I am palling to use Bank 1 and 2(3.3V) for the input and outputs. I don't need to use Bank 3 (1.8V) as my machine is not that complicated. 

Are all Pins from Bank 1 and 2 usable as Inputs and Outputs or are there special pins which need to be high or low at boot?? Similar to some Microcontroller?

Do you want galvo for engraving?
How you will implement this because
raster engraving with mesa not supported to linuxcnc.

Just one more thought...

Is it necessary that the write command has pins? Does this data change real-time?
There are several side-effects to this being pins that can change. For example, the documentation lets on that it needs to be written as *one* modbus transaction. (that would mean I first need to fix the bug)

These parameters look like initialization values you set once and leave the same. If that is the case, you can simply make it a single command writing the necessary registers in the <initlist> in one command writing the 5 registers with static data/values in one transaction.

Hello, (author of the hm2_modbus driver calling...)

First, what is the error code generated? See the hm2_modbus.0.command.NN.error-code pins.

Second, what LCNC version are you using?

Just a comment on the attached documentation image:
Reading and writing registers are, in modbus terms, always multiples of word (2-byte) quantities. The image with the "Home position return speed" at register address 0x6099 states a /single byte/ and then two 4-byte words. The documentation is slightly misleading. It states in the next column that 5 registers are actually involved, so that would indicate that the first is masked to a byte sized value (masking is not supported or performed by the hm2_modbus driver). The 5-register statement in the table would also fix the problem of having 32-bit words seemingly on a odd address boundary. But with 5 registers, then the "number of entries" value is at address 0x6099 and the two 32-bit words are at 0x609a and 0x609c resp.. BTW, I notice the interesting mixed endianess of the 32-bit values...

The read operation seems to work as intended, but the write operation fails. The failure is apparently not a problem of the mbccs file. It is an error message of the hm2_modbus driver that indicates something odd is happening.

When compiling the mbccs file I get a couple of warnings (using first file below):
mrje70a.mbccs: warning: Multi-register type 'U_CDAB' not aligned to natural boundary in commands/command[1]/pin[2]
mrje70a.mbccs: warning: Multi-register type 'U_CDAB' not aligned to natural boundary in commands/command[1]/pin[3]
mrje70a.mbccs: warning: Multi-register type 'U_CDAB' not aligned to natural boundary in commands/command[2]/pin[2]
mrje70a.mbccs: warning: Multi-register type 'U_CDAB' not aligned to natural boundary in commands/command[2]/pin[3]

But, that should not be the case. This is an error in mesambccc not being able to count correctly. Using the --verbose option clearly shows the address to be even. I have to investigate and see what is happening. I am guessing that the hm2_modbus error is secondary to an error in mesambccc when setting the command and pin fields for the command lists. As a temporary fix: splitting the read and write commands into two separate commands makes the warnings go away (second source below). It /might/ fix the read/write issue you are having. The downside is that the read/write no longer is one single modbus transaction. That may or may not be a problem, depending the device.

The way you wrote the definition should work. I'd write it like:
[/code][/code][/code][/code]