Advanced Search

I measured again

from +5V to DIR+ = 5.13V and drops to exactly 5V when jogging in the negative direction


from +5V to DIR- is always at 0V That's for all channels on TB2 1, 2 and 3

Do you think i got a faulty board, Sorry this is getting so frustrating

The signals are differential but can be used single ended
That is DIR+ and DIR- should both change voltage when
the direction changes but one should change from 0 to 5V and the
other from 5V to 0 (relative to ground)

Measured differentially, you should always measure either
+5V or -5V across the DIR+,DIR- or STEP+,STEP- pins.

spumco wrote:

I consider any of the Mesa SmartSerial boards to be 'direct I/O' as that method of connection is rock-solid and there's no human-perceptible lag or latency.  Which means a hand-held MPG with a 7i73 inside (for the digital display) will be be just as responsive as the panel-mounted stuff I built.

Well there are wireless pendants that wire into direct I/O (but they are not USB) that will give equivalent response
www.wixhctech.com/product/23.html
They use a lot of I/O but you can get versions that use digital inputs (which I have used) that save a few inputs
 

Yeah i checked it in halshow under parameters
step_type is 0

devils4ever wrote:

Thanks for your input. That makes sense. Is it worth trying some ferrites?

Are there other brands/models that are more reliable and easy to configure with LinuxCNC?
 

Clip-on ferrites are cheap on Amazon if you want to try it.

Is it worth trying?  Up to you.  I got fed up with the iMach even when it was working.  Because it uses USB - and possibly because of how it's programmed - there is a delay between when you stop moving the wheel and when the machine stops.  If you move the wheel fast back and forth, you can get to the point where the machine is moving opposite to the wheel direction.  Totally unsafe.

I got used to industrial machines with "direct" I/O MPG's and control buttons.  On those machines, there is zero perceptible delay between control input and machine response - even to the point where big machines will jump and jerk trying to keep up with aggressive commands.  Having experienced that, it's like the difference between driving an F1 car and a 1970's Oldmobile with worn-out suspension, spongy brakes, and a sloppy throttle cable.

My personal preference is a standard A/B quadrature encoder, connected directly to Mesa inputs. All critical controls (cyc start/stop feed hold, RRO/FRO/SRO, continuous jog buttons, etc) are also direct inputs.  No microprocessor, no cool features, no wireless/wifi.

I consider any of the Mesa SmartSerial boards to be 'direct I/O' as that method of connection is rock-solid and there's no human-perceptible lag or latency.  Which means a hand-held MPG with a 7i73 inside (for the digital display) will be be just as responsive as the panel-mounted stuff I built.

I have no experience with ethercat (native ethercat device or using a drive's I/O as GPIO), or any of the countless other clever methods folks have devised to expand IO by offloading through a USB or other bus of some sort.

Just take you XYYZ config and modify it by adding an extra joint and XYYZA
At this stage, you need to leave pncconfig or stepconf behind and work directly with your hal and ini

manpages.debian.org/unstable/xinput-cali...calibrator.1.en.html

Is it possible that you have the incorrect step mode chosen in your hal file?

(step/dir is mode 0)

Thanks for your input. That makes sense. Is it worth trying some ferrites?

Are there other brands/models that are more reliable and easy to configure with LinuxCNC?

My Dual Y 3 axis works fine.  I am trying to setup a 4th rotary axis.  I used the setup wizard for steppers.  I doesn't have a XYYZA  option, only XYZA.
i attached the Y step and direction output to two outputs that appear to drive both Y motors on the Halscope. However without having a Y0 and Y1 as in the 3 axis setup I am hesitant to try driving the steppers as I am not sure they will both act in the same direction.  Looking at the 3 axis setup I would need 5 joints (0.0.0.0.0) to do this.  

Would greatly appreciate some insight.

Thanks in advance

I have a P4-S I abandoned a while ago due to flakey behavior and annoying USB lag/latency.  Solid, feels great, nice features... but unreliable for me.

I believe they are very sensitive to RF or EMI through the USB connection.  I've read a number of reports of similar issues - random resets.  One thread I read (maybe not on this board, cant remember) indicated the user could brick his iMach at will by stepping on a rubber anti-fatigue mat while holding the MPG.

When I had mine apart I realized the USB cable shield isn't connected to anything inside the MPG housing.  Not to the pcb ground, not to the case - just clipped short.  No way to dissipate static or anything inside (or outside) the MPG.  I'm not an electronics guru, but this didn't seem right.

If you are in love with it and don't feel like dealing with intermittent customer service from iMach, maybe add more ferrites to the cable.

Also - maybe - see if you can connect the cable shield to something that isn't powered on the PCB or housing.  And cross your fingers.

Yea, scaling and all the math made my brain hurt.

First, it helped me to stop thinking of INI file terms like ENCODER_SCALE whenever they are used to set the value of something in HAL.  Think about the underlying pins when working on the math, not the arbitrary INI parameter name.  I got confused (still do) between all the various 'NNN_SCALE' things in INI and would mix up what was affecting what.  Helps when you write them out all in one place:

• encoder.N.scale = [SPINDLE_N] ENCODER_SCALE = 10000
• stepgen.N.position-scale = yada yada yada

So hurdle #1 - spindle and c-axis are in different units.  Spindle is in revolutions, c-axis is in degrees.  This causes brain hurt.

#2 - as you noticed, spindle scale is a velocity thing, so it's a RPM/RPS formula not steps per degree.

#3 - remember that my spindle drive is internally in velocity mode ONLY, and my stepgen is always in velocity-mode... so I don't switch the stepgen position-scale via M102/103.

If you are switching the drive internally, you will almost certainly need to change the stepgen scale for each drive mode.

ec_generic doesn't add or remove any interrupt moderation.
ec_generic is just a layer on top of linux's normal network driver.
 

Thanks, but the USB stick was really broken and it blocks any PC it's plugged into. I'm using the handwheel to modify it with an ESP32.

I have the variator now basically working.

To the 3 problems I laid out a few days ago:

1: The problem was really at 2 points. For one, the line
setp [HMOT](CARD0).pwmgen.05.
offset-mode should have been 1 and was 0, and on top the VFD was set slightly wrong. Using open-loop FOC now, the tuning went much better.

2: The divide-by-0 issue is still somewhat there, but giving both ".in" pins a starting value greater than 0 makes it so it still throws an error at startup but works as expected thereafter.

3: It seems that I cannot manipulate the error term directly, but what works is to take commanded and feedback, calculate the error, and scale that error. With that, I can “reassemble” a feedback that leads the PID component to get the error I want it to.

With all that, I am able to have stable control over the whole RPM range of about 65 RPM to 3000 RPM.

The variator control still has to be improved, but the principle seems absolutely workable.