Advanced Search

gardenweazel wrote:

T99  P99  D+2.000000 Z+0.0 ;3D Probe
 
 

my tool table looks like this:

T1 P1 X0 Y0 Z0 A0 B0 C0 U0 V0 W0 D2.00000 I0 J0 Q0 ;touch probe

Z0 is included in all of them. When changing tools to a new tool, strange Z values ​​occur which are then entered into the tool table at Z when the tool is changed.

The new milling cutter then has a value of 155.34 at Z and then wants to travel 214.45, for example.

even though my maximum travel distance is only 145 in Z

gardenweazel wrote:

Basic Probe and Versa Probe are two different programs.

 

I know that there are two different ones. I just wanted to check whether the error occurs there too

I have a question about how to connect the STEP DIR motor control outputs. Since they are not differential, one of the input pins on the driver is common. Which is common, the negative or the positive of each driver input?

The 7I77/7I77D have no flyback diodes but they do have Zener --> gate
slew rate limiters. These dissipate the inductive energy in the output MOSFETS
This is only good up to 60 mA or so. If the solenoids have more that 60 mA  current draw,
they must have flyback diodes (and they must draw no more than 350 mA)

More information is needed, Does LinuxCNC run?

If LinuxCNC runs and you don't get communication errors ("error finishing read!")
Your issue is not likely Ethernet related.

I mean connect all drives ENA+ lines to OUT0-
All drive ENA- lines to ground, and OUT0+ to +5V

This means when OUT0 is enabled, all drives are enabled
it really doesn't make sense to have per drive enables
as it wastes outputs and there is typically no operational
advantage with individual enables.


 

I would like to thank you again for your help

it's a bit of acrobatics with the computer mouse,

after several attempts, it seems to me that it would be much better with a single, shared multiplier for crosshair angle or also for circle diameter

Basic Probe and Versa Probe are two different programs.

It appears to me that Basic Probe has fewer options than Versa Probe.

The documentation for the two should be separate as to not confuse the reader. I see if I can add some value to the docs.

Got a 6i25 and 7i77d in front of me and i am ready get things started.
I got myself an old office PC to get things going and will migrate to a DIN Rail PC with a proper touchscreen once everything's running.
A few questions straight after studying the 7i77 manual and ripping out lots of cables from the machine.
Can i sink solenoid power straight to the 7i77? Does it have some flyback diodes integrated? Is there a max current rating for those sinking inputs? Original Siemens IO cards had direct connection to all solenoids.
Best,
Lukas

I suspect that I may have found out what is going on.

I was reading thru the setup instructions in the qt_auto_probe_tool.ngc file being careful not to
"read-thru" anything that I may have missed. This sentence caught my eye:

The following workflow assumes using both a XYZ probe and a Z Toolsetter:
;    1 - Initial Setup: Before beginning the program, setup the Probe Tool as 
;        having a zero z-offset in the tool table.

My tool table file did not have an entry for the Z-Height of zero. So I added the entry as follows:

T99  P99  D+2.000000 Z+0.0 ;3D Probe

I started the test program that I had and everything worked as intended/expected. However, as it was getting late in
the evening when I tested I tested with a much shorter end mill than my previous tool which was the longest mill in my
inventory. Today, I will retest with the longer tool and report results. I'll have to look in the code and see if I can find where
the tool Z is picked up and see if there's any room for improvement if this is indeed the problem. Hence, if the probe Z has no value,
then assume zero?

 

That reading is enough to continue testing.
Latency test can not test for every scenario/load/whatever happening in a PC, but it is a good indicator as to usable or not usable.

Grotius wrote:

Hi Lcvette,

It's indeed a alternative controller, once it finished.
This can take a long time. Some are good coding day's, some are bad coding day's without good progress.

It turned out, modifying lcnc's code to do thing's i would see accomplished is almost impossible.
Best reason is entanglement.
Then just writing new code from scratch is 10x faster to get things done.

There are no goals for me. It's just a project to try out new things wich got my interest's.

It's not the purpose to outsmart lcnc or something like that. Or claiming thing are better etc.

Altrough it is interesting to find out differences in lcnc and this approach.

Like this has bi-directional hal pins and used modern boost interprocess for shared memory.

Today did a mayor bug fix. It turn's out that multiple shared memory regions updated by thread's, would not exchange data
properly. Even when mutex etc. was set.
In the end it worked by using a single shared memory region for all thread's.
 

Sounds very exciting! like an overhaul of linuxcnc without the constraints of outdated sections.  very cool indeed!

I have a question regarding the current Trajectory planner and since you have been in it elbow deep i was wondering if i could bounce it off you to see if it may be feasible for those of use who are experiencing some pretty bad effects of it.  I don't want to hijack this thread and was wondering if we might chat in realtime?  this is the QtPyVCP chat room link below please feel free to drop in, you can ping me with @Lcvette in the room and I will get a notification!

matrix.to/#/#qtpyvcp:matrix.org

Thanks Grotius, I hope to chat soon!

Chris

Hello expert, look at the picture description, can you optimize the memory usage?专家你好，看图片描述，你能优化内存使用吗？ 

   

hard to tell what is going on without more data, maybe tell us what the work offsets were set at as well as the current dro position readings at the time of the image capture.