OSHW release DE10-Nano Daughtercard

[justin White]

I've decided to release the board I've been working on pretty much as is, just with some open source considerations. It was intended for a specific machine, but I rung out all of the I/O possibillities I could, no DE10 GPIO pin went unused. There is an onboard 5v regulator that will power the nano from GPIO and has a PTC fused connector to power about 3A worth of external whatever. Specs:

9-25v VIN, 

5v regulator powers Nano from GPIO

6 differential stepgen interfaces with 5v enable (for external drivers)

6 differential encoder inputs (single ended encoders pull down encoders work fine as well with no extra wiring)

16 sourcing outputs at supplied field voltage Outputs are done at whatever field voltage supplies the board (recommend 24v)

2 high current opto-mosfet outputs

16 inputs arranged with single 3-pin connectors each to simplify NPN or PNP type switch wiring. Inputs upto 30v

1 RS422 connector interface for SmartSerial. (not well tested, may be issues with MK SS)

On PCB terminal blocks for ground and field V+ that simplify wiring in smaller machines

a 3A PTC fused connector for powering external devices from the overkill 5V/5A regulator (Nano+onboard components probably don't use more than 2.5A @ 5v)

2 scaled analog input interfaces (4 channels each). 5v interface for using potentiometers and such at 5v_ref, and one 4 channel interface that is hardware scaled to accept 0-10v external input. (ADC hal component in repo) 

The stepgens or outputs could probably be configured in hm2 firmware to support PWM. Stepgens would provide differential PWM @ 5v, outputs would be single ended PWM @ supplied field voltage haven't tested PWM yet but there's not much to it.

There are hal files, a gladevcp GUI, and display python file that will set the DE10-FB image up as a test platform for the board. The hal files are examples of pin masking and pin inversion that is done in hal to make the i/o intuitive. It could use some sort of hm2 overlay type thing but that is beyond me. There is also 2 versions of an ADC hal component that will convert the 12bit data from the onboard ADC into a usable scaled voltage input in hal.

The board isn't super cheap, that wasn't the intention but compared  to the BBB hardware it's probably not too bad. It's a fairly large board (200x155), but that's because I prefer Phoenix connectors and overall wiring cleanliness over small form factor stuff. Still working on the git, but it's up.

https://github.com/ShadeTechnik/socfpga-developement-OSHW

Testing a stepgen and encoder:

https://www.dropbox.com/s/qa4ro9r0io0dlvf/Video%20Sep%2022%2C%209%2054%2040%20PM.mov?dl=0

 

[justin White]

If there is interest I may offer assembled boards. Not sure what they would cost exactly, probably $100-$150 but I haven't tried to figure that out yet.

[justin White]

[Michael Brown]

So Mksocfpga is having babies, @Justin congrats with the (first ?) mksocfpga  oshw daughtercard release :-)

Michael

[Charles Steinkuehler]

Congratulations, indeed, that's a very nice looking board!!!

I would suggest adding some PDF files to your github repo, at least
for the schematic. I wanted to review the design, but not enough to
clone the repo and install the newer version of Kicad I'd need. :)

Also a lot of potential users are unlikely to have Kicad installed,
but can probably read a schematic.

--
Charles Steinkuehler
cha...@steinkuehler.net

[justin White]

Yeah Kicad is a mess when it comes to updating.

Currently the BOM likely has some errors at the moment and I'll add some  PDFs when I get a chance.

I've tested everything fairly well and I'm pleased but I'm open to suggestions if you see anything.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/f57204c4-cd19-2b19-9bbc-962d2464db6d%40steinkuehler.net.

[ce...@tuta.io]

Sep 23, 2019, 05:34 by blaz...@gmail.com:

> https://github.com/ShadeTechnik/socfpga-developement-OSHW <https://github.com/ShadeTechnik/socfpga-developement-OSHW>

>
> Testing a stepgen and encoder:

> https://www.dropbox.com/s/qa4ro9r0io0dlvf/Video%20Sep%2022%2C%209%2054%2040%20PM.mov?dl=0 <https://www.dropbox.com/s/qa4ro9r0io0dlvf/Video%20Sep%2022%2C%209%2054%2040%20PM.mov?dl=0>
>
Looks nice. This and the version with an analogue industrial output (instead of stepgens) would probably satisfy majority of traditional home-grown CNC mill machine projects.

Bet the connectors are the most expensive part of the BOM.

BTW, I did install the Kicad. True, only in VM, but still...

Cern.

[justin White]

It was brought to my attention that I should probably have termination resistors on the differential encoder inputs. While it was fine in testing, after doing some research I'd have to agree. I slapped some pdf schematics in there as well. Also improved the differential signal routing.

On Tuesday, September 24, 2019 at 6:13:21 PM UTC-4, ce...@tuta.io wrote:

Looks nice. This and the version with an analogue industrial output (instead of stepgens) would probably satisfy majority of traditional home-grown CNC mill machine projects.

Bet the connectors are the most expensive part of the BOM.

BTW, I did install the Kicad. True, only in VM, but still...

Cern.

I tend to think of analog as being kind of gross for machine control, too much noise over cables. However, It would probably be a good case for looking at the possible issues with Smart serial in MK/mksocfpga. The Mesa 7i83 would probably be a painless solution for analog servos, and a better setup because you can put the 7i83 in it's own shielded case and keep the analog stuff away from the rest of it and the only thing between the 2 is a chopped up ethernet cable. I just ordered a 7i66-8 that I'll pass on to Michael if that fares the same as my 8i20 (discovery happens then faults out and drops comm.)

Hopefully mksocfpga will get a little more traction, there's some really good use cases for it. From an all in one HMI type deal to what I think would be a pretty capable remote machine control setup.

[justin White]

So i got my 7i66 and I have no problems discovering it, reading and writing to the I/O over Smart Serial. This is the same version of my board that can only manage discovery with an 8i20. So at this point I'd say SS is fine in mksocfpga, the rs422 hardware on my board is fine, and I think the 8i20 hm2 driver in MachineKit is broken unless someone knows otherwise.

Any of the MK devs able to take this on?

[Michael Brown]

I would no rule out the 8i20 itself in this equation:

Does it run firmware, and can this be reflashed ?

Can their be a faulty baud rate setting ?

Can you retest the 8i20 on a different setup to confirm that it works correctly,

if so can you reference this exact setup (software HW etc) ?

Michael B

[justin White]

The 8i20 and some other remote cards run a microcontroller rather than an FPGA. It's a torque mode motor drive so an FPGA would be overkill. I don't know about changing firmware on it, not going to say it's not possible but it's not a thing like the FPGA cards. Instead you can flash non-volatile parameters. All SS devices run at 2.5mbaud changing this on the 8i20 when the intention to have it communicate with another Mesa SS device would be a mistake. However since I don't want to be "that guy" I did double check.

swrevision = 139

nvrembaudrate = 9

index 9 for nvrembaudrate is 2.5mbaud as per manual. The card is about 1 year old so it should be fairly recent software on the card. 

One thing that is probably of interest is the 8i20 and the 7i64 cards are older than hm2 autodiscovery. Discovery is done via a matching driver rather than the firmware saying "tell me who you are and what you do". If the 8i20 sw has changed in a way that matters over the years it's almost guaranteed that LinuxCNC updated it's driver, who knows if MK ported the update since the fork. 

There's nothing for me to change and re-test, the only thing I know that matters other than the hm2 driver is the baud rate, which confirmed is correct.

Working setup is an x86 running LinuxCNC 2.8pre1, a 7i76e connected to a 8i20 over SS.

Setup that does not work with 8i20 but does work with 7i66 is mksocfpga firmware built 2 weeks ago with docker, mk-hal and mk-cnc updated like a month ago. Same 8i20, my hardware.

[Michael Brown]

@Justin

Have you seen I have put up a new lcnc mk sserial mod for you to test ? (direct download link)

Michael B

[justin White]

@Michael,

Yeah I tried it and same results. I posted a response on git. I just blew up the brake resistor on my mill so I pulled the 8i20 out and it's on the desk. I did re-verify that merely just plugging the 8i20 into the 7i96 SS port on my other LCNC machine results in the 8i20 having 0 comm errors and a status heartbeat without a HV power supply or Motor attached. My nano is all setup for SSH/VNC so if you want I can give you connection details and you can see if you can get MK-hal working with it. Seems like it's a handshake issue, as I said the other SS cards auto-discover, the 8i20 relies on the SS driver having certain knowledge of the card.

[Michael Brown]

@Justin I just put a new suggestion into the git thread...

On Sunday, 29 September 2019 20:01:43 UTC+2, justin White wrote:

@Michael,

Yeah I tried it and same results. I posted a response on git. I just blew up the brake resistor on my mill so I pulled the 8i20 out and it's on the desk. I did re-verify that merely just plugging the 8i20 into the 7i96 SS port on my other LCNC machine results in the 8i20 having 0 comm errors and a status heartbeat without a HV power supply or Motor attached. My nano is all setup for SSH/VNC so if you want I can give you connection details and you can see if you can get MK-hal working with it. Seems like it's a handshake issue, as I said the other SS cards auto-discover, the 8i20 relies on the SS driver having certain knowledge of the card.

I must admit to having near zero experience with SSH/VNC, so initially (for me as a HW guy) it would seem to me a lot like trying to debug via poking a stick thru a hole in the dark ... :-)

[Michael Brown]

@Justin

I just created a PR including the boards bitfile, I recon the lase edit of the  PIN config file is in order else place your corrections as a commit message.

Best wishes

Michael B.

[justin White]

Forked and created a new PR, git is not my specialty. "dc1f" wasn't "released", dc1G is the correct config. I don't see any bitfiles in mksocfpga, only pin files. If you want me to PR the bitfile let me know where it goes.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/a966b8b2-ac8e-4c8f-831e-c481ef8ddc44%40googlegroups.com.

[Michael Brown]

Yeah you fumbled and things looked a bit odd on Github until I  understood what you had attempted, no biggie :-) (wrote you some notes there)

---

The Bitfiles are generated and distributed via a online build system in apt packages:

Whats not so apparent is that when a PR to the mksocfpga repo is merged (always by someone different than the submitter as a rule),

this merge starts first an online bitfile builder that builds the bitfiles for both the Quartus and the Vivado projects, 

afterwards these bitfiles are piped into a package build system 

that first puts the new bitfiles into debian packages(named socfpga-bit and socfpga-rbf), and lastly exports them to the machinekit repo.

(if all goes well)

'This whole build process takes somewhere around 2 hours.

---

Next time a machinekit(socfpga) user then does:

sudo apt update && sudo apt upgrade

The new bitfiles are then pulled into his/hers system and automatically placed in the correct folders.

On Monday, 30 September 2019 23:21:07 UTC+2, justin White wrote:

Forked and created a new PR, git is not my specialty. "dc1f" wasn't "released", dc1G is the correct config. I don't see any bitfiles in mksocfpga, only pin files. If you want me to PR the bitfile let me know where it goes.

To unsubscribe from this group and stop receiving emails from it, send an email to machi...@googlegroups.com.

[justin White]

All else fails just get the pinfiles from here:

https://github.com/ShadeTechnik/socfpga-developement-OSHW/tree/master/DE10-Nano/ST-DC1%20daughtercard/mksocfpga%20Config%20files/DC1G

[Michael Brown]

No problem be patient until "someone" has merged the first PR

Then All you have to do afterwards is following: handy to learn exercise :

First make sure you have your new work on a branch:

git checkout -b pin-work

then:

Syncing your fork 
https://help.github.com/en/articles/configuring-a-remote-for-a-fork

https://help.github.com/en/articles/syncing-a-fork

this leaves you on your master branch and you should see the newly merged commit doing a 

git log 

-->   (press q to get out)

then you do a rebase to place your work branch on top of my PR (at this point in the upstream machinekit mksocfpga repo)

git checkout pin-work

git rebase master

next you then make sure you have the new pin file and you delete the obsoleted one.

git rm <old pinfile name>

then you update and sign the commit

 

git commit --amend   or git commit -a --amend (if you didn't use git delete)

then you commit is ready again for PR ... :-)

[Michael Brown]

Ups forgot the -s for signing:

git commit -s --amend   or git commit -a -s --amend (if you didn't use git delete)

On Tuesday, 1 October 2019 01:56:29 UTC+2, Michael Brown wrote:

No problem be patient until "someone" has merged the first PR

Then All you have to do afterwards is following: handy to learn exercise :

First make sure you have your new work on a branch:

git checkout -b pin-work

then:

Syncing your fork 
https://help.github.com/en/articles/configuring-a-remote-for-a-fork

https://help.github.com/en/articles/syncing-a-fork

this leaves you on your master branch and you should see the newly merged commit doing a 

git log 

-->   (press q to get out)

then you do a rebase to place your work branch on top of my PR (at this point in the upstream machinekit mksocfpga repo)

git checkout pin-work

git rebase master

next you then make sure you have the new pin file and you delete the obsoleted one.

git rm <old pinfile name>

then you update and sign the commit

 

git commit --amend   or git commit -a --amend (if you didn't use git delete)

then you commit is ready again for PR ... :-)

Michael B