loadusr -W lcec_conf ethercat-conf.xml
loadrt lcec

loadrt ddt names=spindle-v
loadrt mult2 names=rpm-calc
loadrt near names=spindle-at-speed
loadrt lowpass names=spindle-filter

addf rpm-calc servo-thread
addf spindle-at-speed servo-thread
addf spindle-v servo-thread
addf spindle-filter servo-thread

addf lcec.read-all servo-thread
addf lcec.write-all servo-thread

setp lcec.0.El5101.enc-pos-scale 2000

net spindle-pos-fb lcec.0.El5101.enc-pos => spindle-v.in => spindle.0.revs

setp rpm-calc.in1 60
net spindle-rps spindle-v.out => rpm-calc.in0
setp spindle-filter.gain 0.1

net spindle-rpm-raw rpm-calc.out => spindle-filter.in
net spindle-rpm-fb spindle-filter.out => spindle.0.speed-in

setp spindle-at-speed.scale 1.1
setp spindle-at-speed.difference 10

net spindle-vel-cmd spindle.0.speed-out => spindle-at-speed.in1
net spindle-rpm-fb => spindle-at-speed.in2

net spindle-at-speed-sig spindle-at-speed.out => spindle.0.at-speed

net spindle-index-enable lcec.0.El5101.enc-index-c-enable => spindle.0.index-enable

net spindle-rpm-fb => pyvcp.spindle-speed

If you want to contribute to the pyside6 branch you can use the new Trixie installer in my GitHub, but this is for development use only, not for machine use yet.

It's still work in progress, not ready for official release yet. Once it is it will be available for normal install with updated docs. The latest vtk edits are still in a testing branch and have not even been merged into the pyside6 branch.

How about the SIM, does the SIM start and work as expected? If so it's almost certainly a config setting issue.

This sounds like maybe an estop conflict. Or perhaps a post gui hal file issue.

Needs to be done with physical wiring
 

Thanks, that sounds like exactly what I need. Do I need to connect it electrically or can it all happen in hal?

Hello Tommy thanks for your response, yesterday in follow up to your suggestion I set the parameters as I will show in the pictures below and I have some updates:For the first time THC stayed enabled during the cut, this happened around once every 5-8 tries, dint have the chance to validate it worked properly but that is some progress.*Something that i was not doing before is to set same speed in material table as well as in the G1 command of the G code idk yet if that has something to do with it, please see the next items.*Normal behaviour in my setup is that screen always went black for a second or two right after the pierce, it was so consistent that thought it was a feature of the GUI, yesterday noticed only a few runs where the screen did not go black, some of those matched the times where THC remained enabled. I checked and seems that the black screen is rather an issue caused potentially by EMI?*Changed plasma source settings to increase pilot arc and I could see the screen going black more violently. i.e. with flickering before going black.I am making some improvements to grounding to see if this helps, do you have any recommendations to make the arc ok, feature more resilient? in case that it is emi or do you have any other idea thanks. 

 

If you want to, you can loop back a step/dir channel to the 7I96S's encoder
Step to A and DIR to B  with the encoder set to UP/DOWN  =  counter mode

This is how the hardware Step generator was originally tested

masawee wrote:

just found this manual matic pendant, but teensy 4.1 is too expensive ower price board, can i use teensy 2.0 this ? lot lot cheapen, and what need dong encoder or other library, ?not understand english good, need change arduino ide encoder library to new and were have ? i come old teensy 2.0 USB pendant all time only errorrs whit encoder.h
no declare scope etc. i not know what this all mean. not need diplay , only encoder and rotary SW change acis and scale. can move XYZ remote controll. were i found code teensy 2.0 can use. this.
 

Hi - the project is based around the Teensy 4.1 to ensure responsiveness from both inputs and the display. Technically you could use a Teensy 4.0 on the PCB (ir I created a common footprint) but I have not tested this and you would not be able to use the 5 physical buttons below the display.
If you don't need the display, this is probably not the right hardware to base your project off but the Manualmatic Python Component and pendant code is all open source so should help point you in the right direction. A Teensy 2.0 would no doubt be more than enough to run an MPG and an encoder button or two.
The Encoder (`encoder.h`) library is designed/written by PJRC for the Teensy range and is extremely reliable, so not sure why you are getting errors. You could use my InputEvents library (in Arduino IDE  and PlatformoIO library managers) to make it easier to use the base Encoder library.
HTH

I thought about that, so I marked the position of the pulley on the motor and ballscrew, but they didn't move and the belt didn't skip. Also the ballnut mounting and the bearings on the fixed side of ballscrew have no backlash.
I think the primary problem is the 455 steps/mm. The microstepping is set to 3200, the motor pulley is 20 teeth, the ballscrew pulley has 30 teeth and the ballscrew pitch is 10mm. That should be 480 steps/mm, but if I set it to that it moves about 5% farther than it should. I should somehow count the pulses coming out of the 7i96s, but I haven't been able to convince my oscilloscope to count reliably. Is there something in halscope that would show that?

With further testing, I'm seeing one weird quirk that I can't quite figure out.

I would like the two sets of clamping radio buttons to also indicate the state of the clamps. Because the clamps can also be activated/deactivated by custom M-codes in g-code, or by set of physical buttons on a user panel on the other side of the machine, I added some hal pins in the call back file to set each radio button active. The real buttons and M-codes all work as expected as I want them to. But when I press the unclamp button in the GladeVCP the clamps, unclamp then reclamp, then unclamp again. (And I have not even connected or used any of the hal pins I've added yet.) The GladeVCP clamp buttons seem to be working correctly.

Any ideas?

Many thanks to the community.
I choosed Ventoy. Very useful tool.
Rufus stays for workaround with Win 11 install.
Balena sometimes is problematic with arm images for me.

Good luck for you all,

/eugenius.

If the problem stays with the X axis with motor driver and 7I96S channel changes,
it really sounds like the issue is more likely to be mechanical than electrical.

i was aware that i would get max. 1500-3000mm/min out of the COM Port. This would bee acceptable, as i will mainly use LinuxCNC as an ELS option with the occasional automated part (switching axis off when hand cranking of course)