Advanced Search

greg23_78 wrote:

i think i'll keep the potentiometers, because i've never coded a homing with an encoder so this will allow me to improve, and if i never manage to, it's easy to dismantle so i could insert home switches.
 

Nice.
I will try to get my mother to have a look at the pictures, she still uses those machines daily despite being 75 years old.

Could you post what and how the changes you made were?
Thank you.

I'm trying to identify each component to find out how this embroidery machine works.

I have two rotary solenoids that operate elements in the bobbin.

I presume that this lever locks the bobbin. Is this correct?

 

For this component, I'm not sure. At first glance, I have the impression that it cuts the thread, but I have a rotary solenoid on the upper arm.
The way it works, when the rotary solenoid is active, it engages the system and the component moves back and forth when the needle is up and stays in the position shown in the photo when the needle goes down and up.

 

i'm sorry i'm back so late, i was in the middle of cleaning the machine.
i think i'll keep the potentiometers, because i've never coded a homing with an encoder so this will allow me to improve, and if i never manage to, it's easy to dismantle so i could insert home switches.

 

Nope, did not work for me either.
This does work, needs a bit of editing if you need faster step rates than 16kHz, i got it to 40kHz without issues and fixed a strange issue where it would sometimes send steps back and forth after a jog.
github.com/jzolee/HAL2UDP

I did, but i forgot, sorry.

kworm wrote:

Sorry to post on a old topic but I wanted to see if this functionality was in qtplasmac in the 2.9.4 install or if you need to be running from the 2.10 master?  Also, has anyone done moving piercing in Fusion360 CAM?

You really should read the previous post.

Yesterday evening i was using chatgpt to help understand some of the nuts and bolts of what certain values mean. i made progress but perhaps you can check its homework.

i did set the following errors wider which has prevented this error occurring for the most part, though i understand this should eventually be taken right back down to the tight window it should be.
FERROR = 10
MIN_FERROR = 5

notably, it suggested changing the PWM scale from 10 to 1, claming that this would provide the expected +-10V and the voltage limits coming from the max outputs which on the surface makes sense and got me to the point where i was tuning a motor that was either violently oscillating or buzzing angrily, tuning pid values to a very low point gave a quieter (but not silent) motor but it was sluggish.

Now it could be that im not in a position to tune properly, or i could have screwed the code up much worse because i am quite aware that chatgpt is not our savior and it will be confidently wrong.

the documentation here supports the claim that the scale should = 1 however im not certain why mesaCT set that scale as = 10

www.linuxcnc.org/docs/html/man/man9/pwmgen.9.html

feels like progress, and i dont think im far off cracking it.

jhandel wrote:

Howdy all,
     I am working out the high level architecture (and ordering) for a Ethercat retrofit of my CNC Mill ( its VFD is dying and its as good an excuse as any to re work may decisions I made on it when I converted it to LinuxCNC the first time).. 

Anyways, I am looking at the MPG and realizing that I have open IO pins on my pi (like all of them).

So here is my current "plan" for I/O which I would love feedback on 

1x EK1100 - Ethercat to FieldBus coupler
2x EL1819  - 16 inputs (I need 28 so 2 it is) - (the response time is killer vs the EL1809)
1x EL2819 - 16 output (need 11 so that works)
1x EL5151 - Encoder for the MPG  <-- this is where I would love feedback because this guy is $250 used

The really open question is what risks on integration and general PITA am I facing if I use my Pi's IO pins to handle MPG encoder rather than the spendy EL5151. 

I plan to use either Leadshine or Innovance mult-turn servos for all of my motors and spindle so my only current known need for an encoder is the MPG...  This is less a question of "can I mix Ethercat with Pi IO pins" and more a question of "should I"... Am I setting myself up for sparks and pain getting the realtime thread where the Pi IO will come in syncing with the rest of the system that is all running on the Server Thread? 

To that end, should I be using other parts of the Pi's IO for emergency stuff like e-stop? 

Thanks in advance. 

The pierce delay starts from when qtplasmac gets an ArcOK signal signifying that arc transfer has occurred. If your synthesized arcOK is off, you will have problems.

Do yourself a favour and wire in the machine's arcOK signal. The time you will save stuffing around trying to get a synthesized arcOK working will more than cover the time you will spend wiring it in properly.

Thanks for the reply
This version doesn't work?
github.com/SybexX/ESP32_LinuxCNC_MotionController_RealTime

I am still looking into this, I did make a small change to the encoder driver to simplify
the index spacing detection. (I added the option to not zero the position on index detection)
This should simplify the distance coded index detection hal component, otherwise I would
have needed to undo the encoder position zeroing in the hal component, and that was pretty ugly. 

I would try setting the following errors wider so you can see the actual behavior without getting an instant following error
(say 25 and 25 mm)

Then first set the PID up with all terms 0 except a small amount of P

Then check if the motors roughly hold position and move when jogged

 

Please read the post fully to understand why this is necessary.

I will get this posted as soon as I can. Thank you.