Advanced Search

There has been a major re-write of the linuxcncrsh interface. 

• C-style string handling has been replaced with std::string and C-style arrays now use std::vector (that should fix the buffer overflows ).
• Many commands have been streamlined in what they allow as arguments so that similar commands use similar arguments (like -1 for 'all' and defaults)
• Output of commands has been streamlined to use identical format for same type of information
• Axis and joint indicators are now checked whether they actually are available and result in an error if they are not
• Error checking is consistently done on arguments and messages returned when something is amiss
• Heartbeat from the servo-thread (motion controller) is used to prevent RT <--> non-RT races
• GET INI - now works and you can read any INI file entry
• GET INIFILE - works and returns path of INI file
• GET PROBE now issues an MDI G38.2 because it [cw]ould not work otherwise.
• GET CLIENTS returns who is connected
• SET DISABLE lets you downgrade own connection from being enabled and also allows other clients to be downgraded
• SET JOINT_HOME (alias: SET HOME) now works in conjunction with SET JOINT_WAIT_HOMED to wait for completion
• SET JOINT_UNHOME lets you unhome any joint
• SET TIMESTAMP lets you enable date+time stamped responses
• Files read/loaded are now using a functional path (as set by the 

  -d

   command-line option). The default is 

  $HOME/nc_files

  . You can pass your own ':' separated list to the 

  -d

   option

Several GET/SET commands were removed or deprecated:

• COMM_MODE - removed - the communication is always ASCII.
• CONFIG - removed - was never implemented
• SET_WAIT - removed - was already deprecated (replaced by WAIT_MODE)
• COMM_PROT - deprecated - API versioning is overrated and is non-functional anyway
• UPDATE - deprecated - emcStatus updates are better left to be automatic
• UPDATE_STATUS - deprecated - emcStatus updates are better left to be automatic.

If users who are using linuxcncrsh and the master branch could feedback any comments or problems, that would be appreciated. 
(please comment in this thread:  forum.linuxcnc.org/41-guis/58443-linuxcncrsh-updates#343698 )

Please comment here about any issues found with: forum.linuxcnc.org/29-forum-announcement...pment-version#343699

 

So wie ich das lese, willst du den Motor als Spindel einsetzen....
Wenn ich all deine Wünsche berücksichtige, landest du bei Kollmorgen. Das sprengt aber dein Budget 

hmnijp wrote:

Marcos wrote:

A “HAL-only second planner” is technically possible, but then you own all the safety, limits, interlocks and coordination logic yourself — and it tends to become fragile fast.
 

If the toolchanger robot only requires point-to-point motion and doesn't require circular or linear interpolation, then extrajoints can be used. Basic safety chains, homing, and limits will work as for other regular joints. However, for motion planning, you need to connect the simple_tp or limit3 components. Their motion calls should be implemented in custom M-code (e.g., M100 P1.2 Q23 ...).

oooh. yeah we can 100% just have single axis at a time motion for this.
thanks, ill look into this.

The devices is starting to take shape here

 
 

As a bit of background on the chuck/no-go safety model:At work I requested a machine with a control that includes an integrated safety zone around the chuck (something I had seen on Heidenhain controls).
In the end, I was assigned a lathe with a Siemens control, and I’ve been very satisfied with it — it works well in practice and I can program effectively on it.However, the concept of having the chuck geometry considered in the motion/safety logic stayed in the back of my mind.
Since that idea seemed useful for safe at-the-machine programming, it eventually found its way into LatheEasyStep’s design.

Hi all,
here is a short update on the latest changes in LatheEasyStep:

Step list loading issue fixed
In some embedded QtVCP scenarios, the operation list stayed empty after loading a single step or a full program. The operation list binding is now more robust.

Safer retract/free-travel logic (lathe-specific)
Retracts are now context-aware per operation:

simultaneous X/Z where safe
groove/keyway: retract X out of material first, then Z
drilling/threading: retract Z clear first, then X
Current tool position relative to stock/chuck is now considered.
Extended chuck / no-go safety model
The program header now supports chuck-related parameters (size, workpiece type, clamping mode, profile) with automatic no-go zone calculation.

New machine/workshop profiles
Quick presets apply typical parameter combinations automatically (e.g. chuck + clamping mode + profile).

Preview improvements
The chuck safety area is now shown in the preview as a dedicated colored zone, including a legend entry.

Save/load extended
New header fields (chuck/profile/no-go/machine profile) are now properly persisted and restored.

My C enable was commented out by accident

Marcos wrote:

A “HAL-only second planner” is technically possible, but then you own all the safety, limits, interlocks and coordination logic yourself — and it tends to become fragile fast.
 

If the toolchanger robot only requires point-to-point motion and doesn't require circular or linear interpolation, then extrajoints can be used. Basic safety chains, homing, and limits will work as for other regular joints. However, for motion planning, you need to connect the simple_tp or limit3 components. Their motion calls should be implemented in custom M-code (e.g., M100 P1.2 Q23 ...).

Hi,

Now that we won't be getting any support from the German PLC forum, I did some searching myself and found this interesting project. In my opinion, it could serve as a good template, as all the code I've seen so far uses a similar topology.

I would also like to emphasize that there is no need to reinvent the whole concept. We already have functioning components (CIA402; homecomp.comp) that form a good basis. Many thanks to @rodw and @MobiusToast for their excellent pioneering work. What is missing now is the further development of these components.
I fear that even this thread, with its good approach, will ultimately be forgotten.

For my part, I will take a different path.
Since I continue to have homing problems and have now ruled out EMC and configuration errors, I think the problem lies with the A6 itself. Yesterday, it took 3 minutes for the x-axis to start the reference run! 
I will now try to expand my system to include battery-buffered encoders.
At least according to the documentation, this should be possible. This would make homing obsolete.

 

Hallo Linuxcnc Freunde,

habe festgestellt das bei dem Handrad XHC-WHB04b-6 die Lead Funktion nicht richtig funktioniert.
Habe an der Treiberdatei pendant.cc die Zeile 346 hinzugefügt. Die "oder" Funktion für die 9b oder 1c wurde ja schon mit einegbaut. Danke an alle dafür.

Bei mir funktioniert diese jetzt und lässt sich aktivieren.
Hoffe konnte ein bisschen weiter helfen. Leider muss dazu Linuxcnc neu erstellt werden mit dem make Befehl.

Habe versucht die Datei mit hoch zu laden, hat aber nicht funktioniert.

[edit]
 

Thanks a lot. I was afraid to hear this but at least I know where I stand now.

Made a start on getting the Schaublin tool changer running. I will use Andy's carousel.comp to control it.


 

That was unexpected. For all the world, it looks like this get stuck in libusb somewhere. After the "is Open" debug text, the code does the following:
1. Function call XhcWhb04b6Component::enableReceiveAsyncTransfer()
2. From XhcWhb04b6Component::enableReceiveAsyncTransfer() call Usb::setupAsyncTransfer()
3. From Usb::setupAsyncTransfer() call libusb_submit_transfer()
4. From libusb_submit_transfer() call libusb_unref_device()
5. In libusb_unref_device() print "libusb: debug [libusb_unref_device] destroy device"
6. libusb_submit_transfer() never returns is my guess
Maybe some deadlock inside libusb. Whether that would be from some bug in libusb or because of some improper handling in the xhc-whb04b-6 component, I cannot say. At least at the moment. I'll look into it some more, but not right now.

Got a crash today. Seems to be the usual way. At mode and screen switch.I have seen that libusb debug printout several times before.Attach are the log and also usb.cc and xhc-whb04b6.cc to be able to follow my printouts. 

rodw wrote:

Affordable and 4500 rpm may not go together! Anything over 3000 rpm is hard to find and not affordable by many standards!

[EN]
The 4500 rpm is the upper limit from the sizing; in real operation I expect something more in the range of ~2240–3080 rpm.
Do you (or anyone else) have recommendations for 400V EtherCAT/CiA402 drives that are still reasonably affordable in that range?
I’d also be happy to look at solutions up to 3000 rpm if that significantly broadens the available options.



[DE]
Die 4500 rpm sind bei mir tatsächlich die Obergrenze aus der Auslegung, ich erwarte im Betrieb eher ~2240–3080 rpm.
Hast Du (oder jemand anders) Empfehlungen für EtherCAT/CiA402-Drives in der 400V-Klasse, die in diesem Bereich noch „bezahlbar“ sind?
Ich würde mir auch Lösungen bis 3000 rpm anschauen, falls das die Auswahl deutlich vergrößert.