-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plasma Up/Dwn signals possibly reversed. #15
Comments
Yes up/down signals are reversed, will fix in the next commit. Until then just reverse wiring.
Tha would be nice, I have not gotten around to make/set up a plasma table yet so any input for the plugin is appreciated. It would be great to get it out of the experimental state. |
Great! We have the same goal. Just posted my ohmic probe idea in "show and tell." I've been testing it a bit and have found something that's not desirable. Ive been trying to dial in a new THC and have been testing on thinner materials. Occasionally the metal moves faster than the THC can react, and the ohmic probe touches the metal. When this happens the Ohmic probe sets off an Estop. I feel like it would be preferable to ignore the pin while cutting giving the THC a chance to catch up. Is that something that can be done easily on your end? I could turn the probe on and off with another relay, but wanted to get your opinion on the matter. |
I have refactored the THC code some, and fixed the up/down issue.
Modifying handling of signals is easy - they can be masked or injected by adding plugin code. I'll have to check why estop is triggered though - probe protection is somehow enabled? |
I think what you're suggesting is manipulating the steps/mm. If so, this could work very well. I'm envisioning a "Speed" variable in settings that would be a multiplier that defaults to 1.00. At the default setting the Z will use the configured resolution and drive Z at the modal feed rate. (1x resolution) If you change the speed setting to 2.00, the resolution would double (2 x resolution), telling the controller it has to make twice the steps in the same time frame, causing the motor to move twice as fast. |
Not dynamically - however I would like to know what your settings for the Z-axis are, including the stepper driver microstepping setting.
When it controls the stepper directly does it output a fixed step rate or accelerate/decelerate it? Some thougths/ramblings: Ideally it would be best to accelerate/decelerate to/from the rapids rate in up/down mode, acceleration is doable but deceleration could be more problematic since it will inevitably produce some overshoot which may cause the position to oscillate. If inside the deadband of the circuitry providing the up/down signalling then likely not... Who knows how it will behave... The best option is of course to use voltage control, then the voltage is used to calculate an error distance that is used to generate rapid moves (PID loop controlled). The acceleration setting in combination with the error distance and PID loop parameters will dictate how fast it will track changes. FYI there are three different metods to inject steps available, and none passes through the regular step generation: In up/down mode it is currently fixed at a 1KHz rate. This could be increased but without acceleration we risk stalling the motor? In voltage control mode step generation is by using an algorithm derived from an article/code by David Austin - this can be run either from timer controlled interrupts (best) or from the foreground process by checking elapsed time (not so good at high step rates since quite a bit of jitter may be introduced). Some drivers supports timer controlled interrupts, some does not. I have tweaked the code a bit more and added a new setting, Virtual ports add support for some LinuxCNC M-codes, Sync Z position will update the Z-position at the end of THC control (when grblHAL changes to IDLE state) so that the core knows where the cutter is. Not sure if this should be an option or not. I'll commit this tommorow. |
I'm currently running 1600 Pulse/ Rev on the drivers and 197.799 on the Z travel resolution.
I wasn't expecting it to, but yes it does accelerate and decelerate. Increases frequency with each additional volt for about 12 volts and then levels off. If the speed is setting is increased or decreased the whole scale is adjusted up or down. Set point 77V Reading on THC 78V Speed setting 50% Set Point 77 Reading on THC 82V Speed setting 50% Set point 77 Reading on THC 84V Speed Setting 50% Set point 77 Reading on THC 78 Speed setting 100% The hysteresis setting on the Proma 150 (up/down model) has a range of 2-30 volts. A 2 volt setting would be (+1 /-1). It's default setting is 8 (+4/-4.) Here is a graph from the manual showing its basic operation. I haven't had a chance to check out the tweaks, but its on my todo list this weekend. |
Hey Terje,
Having a problem with Plasma up/down mode.
Configuration: plasma mode = Up/Dwn. Originally configured "plasma up" = 3 and "plasma down" = 2. Inverted I/O ports 2,3. THC wired wired with "up" to ST3 and "down" to ST2 on E5X controller.
Im testing with Proma THC 150 in test mode. This simulates a floating voltage and sends short up and down signals. THC has torch up and down indicators so the user knows what the intended output should be.
When testing with the above configuration, controller was going up during down signal form THC and down during Up signal from THC. I reassigned I/O ports, Cutter down = 3, Cutter up =2. This corrected controller motor output to match proma THC; However, plasma fly out indicators continue to show reversed output.
On a side note, G65 macros seem to be working great. I couldn't find integration for ohmic probe yet. I wrote a G65 macro for using a relay to accomplish this. Would be happy to post the details if you think that would be helpful to other users.
The text was updated successfully, but these errors were encountered: