Advanced Search

Ich sehe gerade, dass die Chinesen die Aliexpress Anzeige geändert haben und nun zwei verschiedene Karten in der Beschreibung sind. Keine Ahnung was man bekommt, wenn man die bestellt. Ich meine jedenfalls die hier. 

Dieses Fallback Bitfile ist blinkende LED und alle Pins IO. Du brauchst das gar nicht, sondern nur das Bitfile, das zu deiner Maschine passt. 

Die ersten drei Zeilen sind nur zum Testen vom neuen Bitfile, weil es in den flüchtigen Bereich geflasht wird. Falls das Bitfile nicht mit der Karte funktioniert, wird beim trennen und neu verbinden der Stromversorgung das ursprüngliche Bitfile geladen und die Karte ist wieder ansprechbar.
Untere drei Zeilen braucht es, damit es nach dem Trennen der Stromversorgung im Speicher bleibt, aber eben nur wenn das Bitfile mit der Karte funktioniert. Sonst braucht man JTAG.

Deine Karte ist keine 7i98 sondern eine chinesische F7i98. Ist wieder eine andere, zu der ich nichts sagen kann. Mit 7i98 meine ich die hier: de.aliexpress.com/item/1005012092221990.html
Deine kann alles Mögliche sein. Ich vermute, die wird ebenfalls nicht mit originalen Bitfiles von Mesa funktionieren. Jetzt weißt du aber wenigstens wie man es testet, ohne dass gleich alles kaputt ist

Die JTAG Pins bei deiner scheinen anders zu sein, als bei anderen Karten. Keine Ahnung was man da macht. Man kann den IC aber auch direkt flashen (dürfte der zwischen Ethernetbuchse und FPGA IC sein).
Ich empfehle jedenfalls entweder die verlinkte 7i98 zu kaufen, oder die oben gezeigte 7i92, falls 34 Pins ausreichend sind und die 7i98 zu teuer ist. 

Vielen Dank für die schnelle Antwort.
  diese Karte aber Vers. 1.1 habe ich gebrickt und warte jetzt auf eine neue. 
Sie schickten mir diesmal die Doku + Bitfile vorab und schickten anschliessend die Meldung: "Sehr geehrter Kunde, Bitte beachten Sie, dass die Bedienungsanleitung und die Bit-Datei, die wir zuvor gesendet haben, alte Versionen sind. Die aktualisierten Dokumente werden in Kürze an Ihre E-Mail-Adresse weitergeleitet.Alibaba Translation"

Habe eine neue Doku bekommen, jetzt allerdings ohne das 7i98_fallback.bit File. 

Wenn ich das richtig verstehe muss ich doch sowohl den Fallback-Speicher als auch den "Arbeits"Speicher flashen. 1x mit 7i98_fallback.bit mit den ersten 3 Zeilen Deiner Anleitung.
Die Endungen der 3 Zeilen --fallback bewirken das der Fallback-Speicher geflashed wird .

Dann muss noch der Arbeits-Bereich geflashed werden mit z.B. 7i98_5ABOBX3.bit. Wenn am Ende der Zeilen kein --fallback steht, wird der Arbeitsspeicher geflashed. 
Irgendetwas muss ich da doch falsch verstanden haben...
Denn wann werden die Speicherbereiche wirklich geschrieben und nicht nur simuliert ?
Grüße !


 

Has that bug been reported to the Devs?

@JT - 

Thank you for the update and new pins.  I pulled the latest deb and Flex is recognizing the additional spindle connections I put in my test GUI.

This doesn't affect me directly - I have no GUI spindle controls, just displays - but are there similar multi-spindle control pins?  I didn't see any update in the docs about those changing.

A little update as I've found the issue. It was the spindle-at-speed signal. Connected to encoder feedback it would go off in axis mode and I assume it's Gmoccapy behavior that it halts all motion if that signal is false.

Still took me embarrasingly long to figure that out.

HI good mornig at all.
The GUI, can running on Debian 10 ?

Thanks

  Hello to everybody
I use to retofit mill and lathe with linuxcnc , all of them with probe basic.
All of them are working  , i do this for hobby.
Now  i build a hot wire foam cutting machine , a large one , 3m*1,7*1,7 m ,(for 1,2*1,2 section cutting) 4 independent axis
It is configurated with 7i92+7i76 board (old type both of them , remain from other project ) , including the mechanics , remain from projects  , linuxcnc , axis - foam configuration.
On desktop looks like work.
I need an advice , a configuration , an ideea how to manage the wire change of lenght , with a stepper motor , not mechanicaly with spring , pneumatic cylinder , or weight on both sides.
Something like a 5th axis.
I tryed with double y and v axis (vertical axes) ,  mirror axes like routers , XYYUVV  , the mirror axes move and rotate a whell and 'recover' the lenght of the wire , but in my opinion is a better solution , I think with only one motor that can compensate and manage the lenght change.
Thanx in advance
Denis

papagno-source wrote:

The machine with refClockSyncCycles=-1 normally doesn't emit any noise, except for some window movements.
With refClockSyncCycles=1, it emits some noise.
With both refClockSyncCycles=-1 and 1, the command
ethercat upload -p 0 -t uint16 0x1C32 0x01 returns 0x0002 2
Pin pll-error oscillates around -1200 to 1300

When moving windows Linuxcnc's servo loop takes too long time.
There usually is a message in the start window saying that.
If you monitor pll-err in halscope or record it with sampler you will
see a spike in pll-err.
There is some more fundamental work needed to make linuxcnc independent
on such events.
Wouldn't surprise me if this is the difference between 4.19 and 6.

Had another peek at the vid on a bigger screen, and each pass is certainly starting to the right of the previous pass.

Start of pass 2, chip is forming on the right of the insert:
 

Two rotations later, and you can see a second groove forming to the right of the first pass... but it isn't much deeper.
 

Third pass, and now there's a 3rd groove  - also to the right.  And also isn't much deeper.  Maybe deflection, but I didn't see the stock wobbling a ton or climbing the insert.  Almost like it isn't going any deeper each pass, just shifting to the right.
 

In addition to running a no-Q value test, it might be helpful to set up a halscope with the Z-axis position and the spindle index signal.  Try to see exactly where the Z-axis is when the index signal is triggered, and does the Z-axis then start moving immediately?

My earlier suspicion about the start point being the same may not be accurate - hard to spot 0.1mm-0.2mm shift of the insert on video.

Finally, you could put an ink pen in the tool holder and run a series of 3 to 4 G33 moves, using the pen to draw a thread.  Since "The G76 canned cycle is based on the G33 Spindle Synchronized Motion", multiple G33 passes should help you determine if the synchronization start point is exactly the same place without any other motion distractions.

Try it at different spindle speeds - but use the same speed for each set of repetitions.  If you want to test my claims about the bug, run a 4-pass test, but increase the spindle speed by 100-200rpm each pass.

If the start point is the same every time during G33 (same spindle speed) - but not during G76 - you've got a threading-specific problem.
If it's not the same, you've got a more fundamental synchronization problem... mechanical or LCNC configuration.  Or you may be encountering the bug I mentioned earlier from a different direction.

In your hal file, change:

loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[KINS]JOINTS

to:

loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[KINS]JOINTS num_dio=N


where N= the number of DIO needed (1 to 64)


man motion




 

meister wrote:

I'm trying to decide on a connection for my satellites

Ethernet or Firewire Cables, 5V or 24V ?

* RJ45 is cheaper, but could be confused with Ethernet
* FireWire uses thicker cablesCheaper
* satellite boards can be built using 5V, but 24V is practical for many sensors and limit switches
* RJ45 and 5V are compatible with Mesa-SmartSerial (except for the firmware)

Does anyone have any ideas?

I was going to ask you this very question, I would lean towards RJ45, tx with a gnd twisted pair, same with rx. Otherwise a properly shielded/grounded (at the source point only) cable over a short run, possibly with a bit of passive filtering. I think if either are kept as short runs and don't go looping around a spindle drive it should be OK. 

I think keeping the uart at 5v will save level shifting headaches, keep 24v on the machine hardware side of things. I have some PCB's turning up soon and I will try out the satellite expansions, looking forward to it

Longtime reader, first time poster.
Running a cnc lathe retrofit with 2.8.
I was using the y-axis as a drive axis for a tool turret. The y-servo motor moved the turret to the tool position and some simple digital outputs locked it down using an air cylinder. Unfortunately, the system was very "loose" and backlash problems and other repeatability issues meant that it wasn't very reliable. It was a good learning experience and I could get away with using just the 4 default input/outputs that came from a simple configuration.
I've redesigned the turret/indexing system for more effective indexing and this means that I need to unlock more inputs and outputs.
 I'm not any kind of linux programmer. I've used the forum to cobble together snippets of code to make things work and that's been enough for three mill retrofits so far and this lathe project.
I cant figure out how to expand the i/o so that the M62 -M68 codes can call the extended inputs and outputs that are available on the mesa 5i25- 7i77.
I can add and assign names to the i/0 in pncconfig. They show up in the hal file and I can see them in halshow. 
There is a section in hal that shows the only i/0 that  I can access.

#  ---digital in / out signals---

net dout-00     <=  motion.digital-out-00
net dout-01     <=  motion.digital-out-01
net dout-02     <=  motion.digital-out-02
net dout-03     <=  motion.digital-out-03
net din-00     =>  motion.digital-in-00
net din-01     =>  motion.digital-in-01
net din-02     =>  motion.digital-in-02
net din-03     =>  motion.digital-in-03


I know its probably something very basic but I'd like to expand this to include all the i/0 that I select in pncconfig.
I've been through the archives and I'm still drawing a blank. I'm getting errors regarding missing pin numbers and  i/0 max errors.
Any help would be much appreciated.

Solved. 
The problem was my KINS part of the ini. I had it the following:
[KINS]
KINEMATICS = trivkins
COORDINATES = XYYZ
kinstype=BOTH
JOINTS = 4
And they need to Look like this:
[KINS]
JOINTS = 4
KINEMATICS = trivkins coordinates=XYYZ kinstype=BOTH

Thanks for all the help.

for those that are interested

here are some forum links that helped me work out the dual feedback

plus help from Andy and others off forum

wiki.linuxcnc.org/cgi-bin/wiki.pl?Combin..._Devices_On_One_Axis

forum.linuxcnc.org/10-advanced-configura...ectory-planner-et-al

and this forum post below

forum.linuxcnc.org/49-basic-configuratio...ndex?start=10#219431

copied and pasted from the post in case it gets lost


"I don't know if you're still stuck with homing only with the switches or if you solved it closing the loop with the encoders but here's a solution I did on one of our machines (a Mazak lathe) to overcome the problem of homing with index using open loop configuration.

As Peter says, it's not possible at the moment (version 2.8) for LinuxCNC to reset the counters to zero with an index pulse if you're using an open loop configuration with steppers or servos. This is because the index pulse resets the Mesa encoder counters by hardware if I understand it right. 

But, I could find a simple way of solving this with pretty good results. Basically I bypassed the home switch on the final homing stage (when the homing uses the latch velocity) by means of detecting the joint.N.home-state of the joints on the machine. So my homing sequence is working only with home switchs, but when the time comes to do the final home switch tripping, I just use the index pulse to fool LCNC and get a more accurate homing. This is not as good as hardware counter reset, but it's working flawleslly (tested with a dial indicator). The best way to be sure the repetability is good is to use a really slow latching speed.

I hope this serves to anyone facing this problem. This shows again how HAL is amazing when it comes to adapt LCNC to basically anything.

Thanks as always to everyone!"