Advanced Search

PCW wrote:

The spindle needs A and Index or A/B and index.

Note that the MPG encoder inputs on TB3 are fairly
slow so may not be suitable for axis scales.
 

Hmmm....

Lot's of questions and limited knowledge on my side.

Do you know if the isolated encoder inputs are fairly slow because of the opto's or is it the sample speed of those inputs by the FPGA?
If I instead use the inputs available on the expansion connector:
a) Are they fast enough to keep up with the scale data?
b) How would I configure those inputs as quadrature inputs so I can route the results to the DRO display in Linux? Can I do this in HAL?
c) If there is not a way to configure those pairs of inputs as quadrature inputs?

I suppose I could decode the quadrature signals by using a flip-flop in HAL to give direction and then just count pulses for the count, not sure if HAL is fast enough to not miss the counts especially when I do a change of direction? I have a vague image in my mind of a HAL based up-down counter with the flip-flop driving the direction and say the A signal driving the counter clock, hopefully such a counter exists?



Not sure if there is any protection on the expansion pins (I'm guessing direct to FPGA), so either I make a fast isolator board (assuming the inputs are actually scanned quickly) or I take ESD precautions when connecting and just risk it. The DRO pickups will be powered via the 5V on the 7i96s so they will not be powered when the 7i96s is not so will not be driving the unprotected pins when the Mesa board is not energized. Comments/Suggestions welcome.

Here's the plot you requested:
 

This cut is slightly different from the previous ones, as it has a tapered exit for the thread.

The comment about the non-constant exponential threading velocity got me thinking about the threads I cut. I made six. On about half of them, I had to rerun the program because there were tight spots in the threads and I could not easily get the nut on. Running the program a second time, at the same speed, still resulted in some cutting near the bottom of the threads.

I laid the treads up against a 8TPI tap. About half of them look OK, and the tap will sit in the threads without wobbling. The other half, the tap wobbles, or see-saws. Here's a photo of one of those. You can see that the tap is touching on the left side of the thread on one end, and the right side on the other. The reason some of them are OK might be because they were run twice. I don't recall which are which.

 

The spindle needs A and Index or A/B and index.

Note that the MPG encoder inputs on TB3 are fairly
slow so may not be suitable for axis scales.

Hallo, 

nach einigen Änderungen zur Verbesserung der Latenz startet Linux CNC leider nicht mehr. Die Fehlermeldung habe ich im Anhang beigefügt. 

Folgender Hintergrund:
Linux CNC läuft auf einem Lenovo ThinkCentre M91p. Die Ansteuerung der Maschine XXYZ erfolgt über eine Mesa 7i96s. 
Das ganze hat soweit auch gut funktioniert. Beim ersten größeren Job habe ich jedoch die Fehlermeldungen "unexpected realtime delay on task 0 with period 2 000 000 " und "hm2/hm2-7i96s.0: Watchdog has bit ... " erhalten.

Daraufhin habe ich erneut einen Latenztest gemacht der über Stunden auch völlig unauffällig war aber irgendwann kam dann eine extreme Abweichung von 1 300 000 ns.
Gibt es eine Möglichkeit die Ursache zu lokalisieren? 

Ich habe dann versucht mit den Hinweisen aus dem Video von Talla83 die Latenz zu verbessern. Die sehr seltenen Abweichungen der Latenzmessung habe ich immer noch dazu kommt Linux CNC startet nicht mehr...

Testweise habe ich eine neue Konfiguration erstellt (reine Maschine ohne jegliche Einstellungen) auch diese startet nicht. 
Kann mir jemand helfen? 


Vielen Dank

Grüße
Erwin 

 

Take a look at this plot:

 

There is something pathological here as the Z velocity is never constant,
having a slow exponential rise, so the thread does not have a constant pitch.
This is not due to the acceleration constraints but either a hardware/encoder
bug or bug in the threading code.

 This is why I asked for a plot of the encoder position/velocity, to determine if this
is a LinuxCNC threading bug or hal/encoder bug.


 

cmorley wrote:

I would think (in general) encoder resolution, axis acceleration and trajectory servo update rate all have potential to improve the tracking.

but changing the speed significantly is not going to track in the same place with the current code. I wouldn't think it would be hard to code absolute position tracking, but I bet it has some corner cases.
 

If that's the case, it's crazy and broken as any speed variation would  cause threading inaccuracies.
The time to get into sync with spindle rotation can of course vary, but the target Z position must be
synchronized to the spindle angle for the actual cutting path (or it's not spindle synchronized motion at all)
 

I have a two questions I hope someone can answer.

I have a Omron spindle encoder with single ended A,B and I signals, plan to connect these to ENCA, ENCB and ENCIndex.
1) Unless Linux only needs the Ix input?

I also have two scales on my lathe:
The Z scale has single ended quadrature signals "A" & "B" and I plan to use the first two isolated inputs for these IP0, IP1.

The X scale uses differential signalling "A+". "A-", "B+", "B-". I suppose I could connect this single ended to IP2, IP3 but I loose the benefit of the differential signaling. However if Linux only needs the Ix signal (and not the quadrature A and B signals) from the spindle, I suppose I could use ENC A and ENC B for the differential signalling from the X scale.
2) I'm not sure if encoder A, B, and Index are all needed for spindle feedback to Linux? If only the index signal is required can I use ENCA and ENC B for my X scale quadrature signals?
 

kimkar wrote:

Are the QA, QB, IDX pins on the 7i85 equivalent to the A, B, Z signal in line driver encoders?

Yes.
QA = quadrature signal, A channel
IDX = index signal

You are welcomed, always.
Happy new year to all.

Hello,
is it possible and if so how can I read values ​​from qtdragon.pref and use them in a macro or an MDI call, for example?
Best wishes and a happy New Year to everyone. Frank

now, the i2c-bus is merge into the dev branch

many thanks to 'Schoch' , for the quadencoder(z) fixes and the much better rps/rpm calculations.

and many thanks to all other people that helps here, in github and in the discord chat.

epineh wrote:

That is really cool, once I have my existing machine fully tested I intend to start playing around with all the extra stuff you've implemented. When you say several devices per bus, is that now as per the standard i2c protocol, so 128 devices ? I understand that lots of i2c devices only have a couple of address options so that doesn't help.
 

if you have multiple devices that have the same address, you can still use multiple busses on different pins.

but there is also easy support for i2c multiplexer (PCA9548A/TCA9548A) now.



 

and the last files....

This is the file:
399555845-Sd-b3-031-030-00-000-Bosch-Servo-Motor-Manual

split up in 2 sections

 

I wil try to split up the other files, duo to the maximum file size...

these are the files:
Datakabel en Verbinding informatie
Maschinen Datenblatt
Motor Module Parameters

and the:
Elektrodokumentation FP3-50 2860 DIALOG12
Split up in 4 sections

Friendly regards,

Ronny

Hello everyone,As I will soon be starting the conversion of an amazing milling machine myself, I’ve been looking for information about it.
Since there is very little available about the materials and components used, I’m sharing the information I’ve gathered, in the hope that it can help others as well.It’s a machine that uses Bosch equipment, and I’ve uploaded the complete manual, schematics, and everything I have on it.

 Kind regards,
Ronny