LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)

tommylight wrote:

Transistors should work, probably better low side, but do add a resistor between the Tang output and transistor base, something like 470 Ohm or 1K should be OK for normal signaling transistors.
Also, normal transistors do not require resistors between base and emitter for normal switching, MOSFET's do.
 

They normally don't, being current controlled devices, but I have seen instances of ghost activation in noisy environments (transistors do have a Miller capacitance, it's just much smaller electronics.stackexchange.com/a/95984). For prototyping I don't usually bother but if I'm ordering up a board I will add them since they're basically free.

Yes I forgot the base resistor!!!

meister wrote:

digiex_chris post=313820 userid=40887
well, last night I got first movements to work on my iceshield derivative, and got the scale correct. Trying to get my head around the PID settings, I'm a bit lost since I'm normally a stepper guy working with more direct controllers that work similar to parallel port setups, 1 step = 1 step moved, no hunting position. this seems to be treating the fpga as it would treat a servo with encoder feedback. The position doesn't quite reach the commanded position, and it hunts a little, which I find odd for open-loop steppers with no encoder feedback.

Can anyone enlighten me on how to tune this? Is P too high? I have a feeling it maybe should be set to 1.0 instead of the default 250 so there is no gain.
 
the pid-loop is necessary with external hardware, as only velocity information can be sent in this way.

The deviations are actually only rounding errors, which should be no different with mesa hardware.

Remora does it the same way, only with a little trick, there the PID controller is hidden in the driver and linuxcnc does not show the calculated values but those that were sent.

In the beginning I also had the PID controller in the driver (linuxcnc-component), because it was only a copy of the remora driver, but that is actually just optics.

so far, the position has always been accurate to the step...

tuning is also not necessary if you use stepper

Thanks for the explanation. In that case, with the default config, I don't understand why, if I adjust scale, I end up with the position reported to LinuxCNC being unstable. The value in the DRO flickers. The error shown to LinuxCNC is also much larger than I can tolerate, as much as 0.04mm, fickering as much as 0.1mm in either direction. even if the mechanical side may or may not be that accurate, since there is no feedback like an encoder, it should be a stable reported position. The position shown in LinuxCNC never quite equals the commanded position within 3 decimal places, so some of my automation that detects if the table traverse is equal to or greater to the commanded position rounded to even 2 decimal places (in metric) doesn't work. 

Thinking about it more with your comment, I think maybe the machine is moving the correct amount, but the position reported back to LinuxCNC isn't correct or isn't stable, for some reason. How can I look into this further? If it were just floating point rounding error, once the iceshield had arrived at the correct position, shouldn't the reported position then be stable at the rounded value, instead of flicker? My X axis is very coarse, so I am comfortable with it not having high precision, but the flickering reported value (shown in the DRO) is very odd given that it's a stepper.

Do I need to re-flash with each change of scale, or is modifying it in the .ini sufficient?

For reference, 
config: github.com/digiexchris/6x11-sg-grinder-l...reconfig/config.json
generated ini: github.com/digiexchris/6x11-sg-grinder-l...eld/LinuxCNC/rio.ini

but I have changed the scale to 11.64 (yes, very coarse) for the X axis but that's what was required to get 10mm of movement from G1 X10 with a surface grinder table driven off of the normal handwheel (it's quite a large movement per handwheel turn)


I think I'll change the microstepping up to 32k so I can get the scale number higher and see what effect that has on the stability of the reported position.

meister wrote:

On the Tangbob board I use the TXS0108EPW with pull up/down resistors on the input side.

However, to switch optocouplers in the output stages, for example, you still need a driver like the ones installed on the BOB boards (uln2308), the level shifters are not designed for this

Yes, the output of the TX0108E is not directly driving the optocoupler.  There is a simple parallel port Break out board in between. This allows me to switch back to my current linuxCNC parallel port PC and I was able to confirm that the problem is not anywhere behind.

I tried the pullup/pulldown resistor also on the input side, no difference. Forgot to mention that. Anyway, if I don't have the new level shifter by the end of the week, I will see if I can invest some more time in the TX0108 otherwise I just move on to the new level shifter. They were a $1.50 each, not worth spending hours to get them working.

digiex_chris wrote:

.....
Thinking about it more with your comment, I think maybe the machine is moving the correct amount, but the position reported back to LinuxCNC isn't correct or isn't stable, for some reason. How can I look into this further? If it were just floating point rounding error, once the iceshield had arrived at the correct position, shouldn't the reported position then be stable at the rounded value, instead of flicker? My X axis is very coarse, so I am comfortable with it not having high precision, but the flickering reported value (shown in the DRO) is very odd given that it's a stepper.

Do I need to re-flash with each change of scale, or is modifying it in the .ini sufficient?

For reference, 
config: github.com/digiexchris/6x11-sg-grinder-l...reconfig/config.json
generated ini: github.com/digiexchris/6x11-sg-grinder-l...eld/LinuxCNC/rio.ini

but I have changed the scale to 11.64 (yes, very coarse) for the X axis but that's what was required to get 10mm of movement from G1 X10 with a surface grinder table driven off of the normal handwheel (it's quite a large movement per handwheel turn)


I think I'll change the microstepping up to 32k so I can get the scale number higher and see what effect that has on the stability of the reported position.

if i set the deadband to :
DEADBAND           = 0.0001

my DRO shows the exact position like 10.000 or 0.000
 

mBender wrote:

...
I think something like a 74ACT245 where you can external control the direction might be better for this application.

if you are using the china 5axis BOB's, than you can connect it directly to the tangnano9k,
i used this configuration before i draw my first board (Tangoboard).
 

Heureka!! The new level shifter came in today and it works! I used the 3.3V to 12V and supplied 5V to the high voltage line. Even that works. On the Oscilloscope the Input side looks like a perfect square wave, the output side has a raising edge which is not super vertical. It looks like to doesn't make an issue. Will test the 3.3V to 5V lever shifter and see if that makes a difference.

What is the expected behavior of the direction signal. I was expecting that it's either permanently high or permanently low depending on the direction. It looks like that it's either permanent low and high only when a step impulse is created. Meaning it is kind of a square signal too. Is that correct?

Another question: I am running the tang 9k with ethernet. What happens if the ethernet connections drops during a move. Will the motors just stop?

 

 Another question: I am running the tang 9k with ethernet. What happens if the ethernet connections drops during a move. Will the motors just stop?

 

yes, if the connection is broken, all systems goes into eStop, enable pins goes low and no steps will generated anymore

 

Awesome, I tested it this morning again. This is the signal of the output of the level shifter. Looks better as I had it in memory. I also confirmed, the Direction Signal is not a square signal. It's either on or off all the time depending on which direction the machine is traveling. It goes off, once the machine is not moving. I noticed there is sometimes a bit of delay until the direction signal goes off. I was able to see that when I looked at the LEDs of the level shifter.

I also noticed that the machine sounds smoother as when I run it with software stepping.

 

meister wrote:

if i set the deadband to :
DEADBAND           = 0.0001

my DRO shows the exact position like 10.000 or 0.000

Thanks that helped! Also the flickering problem was actually the qtpyvcp UI I was using, not the actual internal machine position, so actually everything is working perfectly.

Here's the github repo for the board including production and assembly outputs for ordering a fully assembled board:
github.com/digiexchris/rio-solidwater-shield