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

Happy Sunday, everyone! 

Got my MPG functional in RIO. Everything works; encoder counts, selection knobs, led, fairly happy about that. Not entirely sure what else I need on that motion control board, probably nothing. And so time to finalize the routing and send out a prototype PCB to test with!! Not that the breadboard set-up doesn't work, it's just a hazardous messland all over my benchtop // flying wires much lol \\

Additionally. If you are designing a Motion Control Board and want to ensure 110% isolation between the domains, the "go-to" part is the ISO7760DBQR (imho). Tested that all of today. Will endure a lightning, two typhoons, and a russian EMP bomb (granted all that are tiny!!). Others; the part's INs/OUTs are HIGH impedance and so no need to pollute the entire board with pullup resistors. 5V-to-3V3 translation at 25Mhz == PASS. Solid square wave with little to no under/overshoot.

The ISO7760 part was specifically engineered for system automation and motor controls, therefore you can officially ditch those half-useless ancient and medieval 'optocouplers'

e.g. 

Mecanix wrote:

Happy Sunday, everyone! 

Got my MPG functional in RIO. Everything works; encoder counts, selection knobs, led, fairly happy about that. Not entirely sure what else I need on that motion control board, probably nothing.
...
 

cool, did you change anything in the hal for this, or did everything work via config ?
if you had to do something to the hal please let me know, then I'll see how I can integrate it


I wasn't completely idle today either

very experimental and only of limited use,
but this example works:

You'll have to find out for yourself what's so special about it,
I only say HAL of hell
 

did i already mention that i have a script to visualise the HAL ?


 

meister wrote:

1. Created a folder ./gtc_custom/mpg/ (i.e. under /Output/LinuxCNC/)
2. Placed mpg.hal inside it (see attched source). 
3. Riogui -> Linucnc -> INI-Defaults -> HAL -> HALFILE (custom) == "./gtc_custom/mpg/mpg.hal"

For the moment this works wonder. Although I bet there are better ways to do it in Rio but I'm way too noob at it still. 

Only source code I've had to change was for the board family to be recognized as a its high-speed C7/i6 type.

/riocore/riocore/boards/MecanixDev/board.json
[-] "family": "GW1N-9C",
[+] ​​​​​​​"family": "GW1N-9C7",

/riocore/riocore/generator/toolchains/gowin/toolchain.py
Line 103:
[+]  if family == "GW1N-9C7":
[+]  prj_data.append(f' <Device name="{family_gowin}" pn="{ftype}">gw1nr9c-017</Device>')

That was the reason my PIN03, PIN13, PIN 15 (high speed bank) was not working. The Gowin was always compiling for a C6/I5 fpga type
But allpins works now!!

meister wrote:

You'll have to find out for yourself what's so special about it,
I only say HAL of hell :P

 

I'll have a look at your HAL, thanks, maybe I can integrate it, but you can also write your hal-file here:

Output/Mecanix/LinuxCNC/postgui_call_list.hal

rio does not overwrite anything in this file when generating

---

yes, it should be something like that, only with the wled plugin,
but that's not what I wanted to show

it's about the new killer feature

you can now write logical links including round brackets in the 'net' field

Sure, as I've suspected there's countless ways to do it better in Rio. Brilliant kit!!

That mpg.hal integration would sure be nice. Not saying this for convenience for myself, but more about the fact that those analog MPGs are extremely common, inexpensive and functioning reliably well. Wired-Rulez!!

I'll have a look at that epic conditional net's (bracket or !bracket) [FEAT]. Haha awesome, just noticed the potential power of that thing; from useless zero-conditional HAL design -to- RIO conditional programming-like HAL. Who would have tought. O M G!! 

I'm going to have to disagree with you on the need for pull up or pull down resistors on inputs, especially with switches (unless the switch is switching to either zero or 5v)and rotary encoder that have an open collector output. Without a pullup or pull down resistor the input is going to float, until that input has a definite logic level on it. With high impedance inputs it requires very very little current to switch the input, if the voltage is at the right level. Generally on a chip such as the venerable 74xx245 when the enable inputs are in the disable state the output is considered to be in a "high impedance state" and is unable to "drive" the outputs.
Honestly any input that is connected via a cable needs a pullup or pulldown resistor for the case of a breakage in the signal wire, especially with an MPG, if teh signal wire breaks you want that input at the board end to held at a known level. The last thing you want is for your input to pick up stray noise and start oscillating. The chip wont "know" if it is a legitimate signal or noise and will pass that on to the other side.
That's why sometimes I feel am opto isolator is a bit better in this respect as the current required to drive the LED in normal situations is a little higher than induced noise in the line.

Never in my life have I designed a digital circuit that takes external off board signals with pullup or pulldown resistors, or inputs that get the input from a SPST switch from an on board switch without a pullup or pull down.