Advanced Search

Like I said, not really a good reason to change.
Right now it's running a really old Minirak drive, basically analog, trim pots, etc. Works but it's starting to fade. My hope is to bandaid it enough until I can swap in something more modern, like from the last decade or so
The 5 volt signal seems to pick up a lot of noise and a slight drop there is a noticeable drop on the motor so was hoping that dropping in a separate supply would improve it and stepping up to 10v might help or at least be less of an affect on the motor speed change.
I'll see what I can come up with between the 12v supplies I've got and the multitude of diodes in other drawers.
Thanks for the input
M

I linked to a post containing absolutely everything you need, and as Andy noted, M67 should be used, not spindle stuff.

Thank you for your message. I have been using the VFD with Modbus this whole time, including rigid tapping, but still interested in your Ethercat setup. You said you didn't need to change the files I shared, but could you share your VFD settings? I image other would find that useful.

I want to clarify something.

My goal in this thread was never to “reinvent everything”.
It was to separate CiA402 logic from EtherCAT transport and validate it deterministically in SIM before going back to real hardware.

Rodw already showed the essential backbone:

• A proper PDS state machine gate
• Only allow homing/motion after Operation Enabled
• Explicit opmode request (6060) and confirmation (6061)
• Controlled homing start sequence

That is exactly what I am implementing — but modularized and testable without depending on a specific drive.

If someone believes this “will lead nowhere”, that is fine — but then please explain technically why isolating CiA402 logic, adding deterministic state transitions, mask/value evaluation, timeouts, and SIM validation would be a wrong direction.

Negative predictions without technical arguments do not help anyone.

Also, individual hardware purchasing decisions (A6 or anything else) are unrelated to the architectural question being discussed here.

The objective is not to fix one specific drive problem.
The objective is to build a clean CiA402 logic layer that can be validated independently and reused.

If anyone has constructive input (state diagrams, PLCopen-style Execute/Busy/Done patterns, hardware traces, mask definitions, timing constraints), that would be very welcome.

Otherwise, I will continue implementing the modular adapter + PDS manager approach and share results for review.

You can look for a "10v reference". Those will output 10V, can be had reasonably inexpensively (either as boards or single parts, based on a 30-second eBay search), and should work so long as you're not drawing much current. That's what I was going to use to control my spindle until I decided that avoiding analog would be ideal (it's a servo, so quadrature input is what I ended up going with).

If a 12V supply will let you adjust it low enough (or a 9V supply high enough), that will also work, and you're not going to harm it at all by doing so unless the manufacturer did something really strange. That's probably the easiest approach.

Series diodes should also work as long as you don't have varying loads. Not a fan of that solution mostly because it's not "right".

If you're up for soldering, plenty of adjustable regulators out there- eg www.digikey.com/en/products/detail/stmic...ronics/LM317T/591677 You can probably find breakout boards for something that will give you 10V by just changing a resistor.

All that said, I would leave it as-is if it's working- the fewer parts/wires/etc. the better IMO. It's your machine, though, so if you think 0-10V would be better or you'd have fun doing it or something, have at it.

Guys, try the attached.  No idea if it works, but it's not giving any errors and outputs data.

I do know about the pot on the PSUs but wasn't sure dialing it down 2volts was a great long-term choice. Dropping in a few diodes makes sense, I'm guessing the current draw on a VFD control would be minimal. I should have a bunch of 1n4001 laying around here somewhere lol.

Thanks
M

Most decent power supplies do have an adjustment pot, clearly visible and marked on DIN rail mount types, not clearly visible on the mesh metal cased ones.
It is much easier to use two diodes in series wired to positive of 12V on one side and to Mesa +10V on the other side, that will drop the voltage by 1.2-1.3V and should be perfectly fine for the VFD. Mind the polarity, the line on the diodes goes towards the Mesa board.

For no real good reason I'd like to change my lathe from using 0-5v to control the spindle to 0-10v.
The VFD is an old VFD05-D230 and it has the options of 0-5V, 0-10V and 4-20mA and supplies it's own 5v if you are using a potentiometer so it looks like I just wired my 7i76 (old version connected to a 6i25 via DB25 cable) in place of the pot. I can't find any way that VFD will supply 10vdc so I need to use an external power supply but most are 5 or 12 (when I say most I mean all the ones I have here and the quick look at meanwell online. Digikey ones quickly jump to well over $100)
I know 0-10 is closer to standard but what are you using for supplies? Is a 12-10 buck converter ok? Can I "turn down" a meanwell 12v to 10 without killing it?
Just asking what some options are
Thanks
 

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.