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)

Thank you for the suggestions. Those are Sino glass scales (KA500 and KA300 TTL 5V). I boosted the signal with npn transistors to 24v (reversing pin logic, shouldn´t matter though) as the smaller scale only gave a 3.3V signal which did not work. The weird thing for me is the working perfectly compared to not working at all, i woud expect a bad/unreliable signal from noise. I will try again on the weekend, putting input on COM1 and Steppers on COM2. Or i finally buy a mesa card ffs . Any suggestions for a standard 2/3 Axis lathe with very little IO ?

My 3 axis router developed an interesting issue a while ago and after a lot of experimentation I'm pretty sure the problem is with the 7i96s.
The first thing that went wrong was that the X axis started moving more than it should. According to math the steps/mm should be 480, but suddenly something decided that about 455 is the correct number. On it's own, that wouldn't be much of a problem, but it seems to occasionally switch to a different number and loose its position.
I have tried the following:
- different acceleration settings (it happily did 3000mm/s2 for a while, returning to within 0,01mm, but sometimes lost steps at 250mm/s2) 
- different stepper drivers, both open and closed loop
- different wiring between the 7i96s and driver
- new linuxcnc installation
- flashed the firmware to the 7i96s again
- completely new configuration through pncconf
- moved x axis from stepgen 0 to stepgen 4

The other axis work perfectly everytime and for about a year so did X, at 480 steps/mm. Z axis has the same motor, driver and encoder as X.
I have access to a 7i96 and I will try it out on friday, but I still want to ask if anyone has a different idea for what could cause this?

Hello,

notice > well tuned RT machine with less then 2us latency

I every time start with the LinuxCNC logo startup file ... create the scope of acc + velocity preview and analyze step by step movement ... jerk 10k m\s3 then I move to the 3d chips and 3d test ... if this works well i am shifting to the my code 1d movement, 2.5 d movement and finally 3d movement .. I start with 0 type then I move to other one for right comparation.. it is freezing TP2 with 3dchips.ngc from default local folder after last update ... no diagnoze possible from my side right now

all step by step analyzing the scopes

Configuration starting basically from axis_mm.ini with custom tool table which is missing from default

Spiking was mainly during start of the scope at servothread and then periodicaly, looks like at each end of segment - but no exact proofing 

I am staying tune for more testing or cooperation ... 

thanks E.