Re: [Machinekit] Re: Goldibox

[Dave Cole]

I agree entirely.  For one-off or low volume stuff, the hardware costs 
become much less important. Speed of development is key.
If a proof of concept works, it can be pushed into cheaper hardware for 
mass consumption.
If software developer cost is $100/hr to produce a proof of concept, 
does it matter if the initial hardware costs $50 or $500?


If you can't afford the $500 development hardware, then you certainly 
will not be able to afford the developer!


Dave

On 11/3/2017 4:01 AM, Alexander Rössler wrote:

I have to disagree here.

A PocketBeagle might seem overkill for controlling an ice box - however,
keep in mind that it significantly reduces development cost.

Development cost is a factor of 10 to 1000 more expensive than hardware
costs, especially for one-off and low volume products.

Machinekit is really good for exactly this purpose, it makes it possible
to experiment and tinker in almost no time.

Btw. I have seen IoT hardware for higher prices with less functionality
- 100$ might seem a lot from the tinkerers perspective, but in
professional environment it's nothing compared to the time you are
working on the product.

Keep in mind that prototyping is an important aspect of modern product
development. Want to prove your boss/investors that an ice box can be
controlled with your phone? -  use Machinekit.

John Morris writes:


[Putting back on list]



On 11/02/2017 12:21 PM, Chris Albertson wrote:
  > The reason we don't see Machine Kit used for things like a thermostat is
  > that would be silly waste of resources.
  >
  > If you want to show off Machine kit using it to do something that is 100
  > time less complex then it's intended purpose is not "showing it off"
  >   Saing "hey look, this software can used to replace a thermostat is not
  > interesting"   If you want a non-machine tooldemo that shows off MK then
  > build a robot with legs that can walk.
  >
  > MK makes an even worse IOT demo.  The point of IOT is that you can build
  > them for i=unde a couple dollars using $100 in parts would look bad.
  >
  > So, if the goal is to use MK  then use it to control a machine that is
  > more complex than an icebox.  If the goal is to build an ice box keep
  > the control budget under $10 or you look silly using so much over kill
  >
  > Perceptions matter.  Using a 64-bit quad core ARM computer to control an
  > ice box just has "bad optics"
  >
  > On Thu, Nov 2, 2017 at 8:25 AM, John Morris  > wrote:
  >
  > [Putting back on list]
  >
  > On 11/01/2017 02:30 PM, Chris Albertson wrote:
  >
  >
  >
  > On Wed, Nov 1, 2017 at 10:50 AM, John Morris    >> wrote:
  >
  >  The value IMO is in the demonstration of a full integration
  > from
  >  electronics to remote GUI, and in the overall simplicity for
  >  learners. Maybe it's the lesson that comes after Alex's
  > AND-Demo.
  >
  >
  > NO, this does NOT demo over all simplicity.  It is very complex
  > compared to that way this is typically done.This is a
  > problem that has been solved 100 times already so we cam see
  >   how others have one it.   OK assuming you want an Phone base
  > point and click app to control and ice box and you want it to
  > serve as a demo to show how it is done then at each step you
  > really should use the "canonical solution".  That is the
  > cleanest and simplest design at each step. and use the simplest
  > and easy to understand interfaces between the parts.
  >
  > Such a demo would have layers, each layer easy to understand and
  > the connection between the layers using an simply interfaces.
  > I'd d it this way
  >
  > 1) physical device.  Ice box the Pelitier heat/cooler.   This is
  > just a Pelteir with a heat sink on both sides,  on heat sink
  > inside and one outside the box, possible with fans on each.
  > Then a power supply and the H-bridge.  You also need temperature
  > sensor(s) inside the box, not mounted to the heat sink
  >
  > 2) controller.  connect to temperature sensor(s) and h-bridge
  > and to control device.It accepts the temperature set point
  > from the user and reports internal temperature and maybe battery
  > stays if this is battery powered.You PID controller loop
  > runs soon this controller. This runs on a tiny micro
  > controller.   The modern equivalent to the Arduino.This
  > controller work independently from the use interface because you
  > don't want to have to runs a computer of cell phone app 24x7 for
  > something so simple at a temperature controller.
  >
  > 3) user interface app.  This runs 

Re: [Machinekit] MachineKit Install directions (Cape, U-boot, Device Tree Overlay confusion)

[Robert Nelson]

On Fri, Nov 3, 2017 at 3:22 AM, Alexander Rössler
 wrote:
> I would love to see the setup.sh files converted to config-pin bbio
> files as here:
> https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/MendelMax-CRAMPS/CRAMPS.bbio
>
> This format is kernel independent and even editable with a graphical
> editor: https://github.com/machinekoder/BBIOConfig
>
> else we have the exactly same problem again with the next incompatible
> device tree change.
>
> I have create an issue for this problem:
> https://github.com/machinekit/machinekit/issues/1310
>
> I think, this would be a great task to solve by someone new who wants to
> contribute to Machinekit.

I see a potential problem with 3.8 -> 4.4.x+ here:

P9_28 spi #SPI CS0
P9_29 spi #SPI MISO
P9_30 spi #SPI MOSI
P9_31 spi #SPI SCLK
P9_41 low #FET 5
P9_42 spics #SPI CS1

P9_29/P9_30 are fine as "spi" but the CSx and SCLK pins are now:

spi_cs
spi_sclk

as usually the spi_cs modes are shared with spi_sclk on the same pin..

considering config-pin loads the bbio file i could fix it up in
config-pin.. ;)  But just a heads up...

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] MachineKit Install directions (Cape, U-boot, Device Tree Overlay confusion)

[Alexander Rössler]

I would love to see the setup.sh files converted to config-pin bbio
files as here:
https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/MendelMax-CRAMPS/CRAMPS.bbio

This format is kernel independent and even editable with a graphical
editor: https://github.com/machinekoder/BBIOConfig

else we have the exactly same problem again with the next incompatible
device tree change.

I have create an issue for this problem:
https://github.com/machinekit/machinekit/issues/1310

I think, this would be a great task to solve by someone new who wants to
contribute to Machinekit.

Jerry Trantow writes:

> Here's the change I made to setup.sh to conditionally use slots with
> kernels <=3.8.
>
> #
> #  Slots changed to device tree overlays after 3.8
> #
> major=$(uname -r | cut -f 1 -d '.')
> minor=$(uname -r | cut -f 2 -d '.')
>
> if [[ $major -lt 3 || ( $major -eq 3 && $minor -le 8 ) ]] ; then
> #
> # Older slots method
> #
> SLOTS=/sys/devices/bone_capemgr.*/slots
>
> # Make sure required device tree overlay(s) are loaded
> for DTBO in cape-universal ; do
>
> if grep -q $DTBO $SLOTS ; then
> echo $DTBO overlay found
> else
> echo Loading $DTBO overlay
> sudo -A su -c "echo $DTBO > $SLOTS" || dtbo_err
> sleep 1
> fi
> done;
> else
> #
> # Use U-boot /boot/uEnv.txt to load capes.
> #
> echo "Kernel version is greater than 3.8, no need for slots. See
> /boot/uEnv.txt"
> fi
>
>
> On Thu, Nov 2, 2017 at 12:17 PM, Jerry Trantow 
> wrote:
>
>> I changed PRUBIN=xenomai/pru_generic.bin to rt-preempt/pru_generic.bin.
>>
>> THANK YOU!!! This got my router moving again.
>>
>> At this point it looks like
>>
>>1. The install instructions could benefit from some information on
>>modifying /boot/uEnv.txt device tree overlay with kernel >3.8
>>2. configs/ARM.BeagleBone.Probotix/setup.sh needs conditional on the
>>device tree overlay load for kernel >3.8
>>3. configs/ARM.BeagleBone.Probotix/CometNP_Metric.hal needs PRUBIN=xenomai
>>conditional
>>
>> I created a pull request for some mention of modifiying /boo/uEnv.txt in
>> the install directions.
>> I have a fix using a conditional to setup.sh to avoid the device tree
>> overlay.
>> There is probably a way to conditionally use PRUBIN=xenomain, rt-preempt,
>> (posix probably doesn't need support?) Does the kernel path need to be in
>> the .hal file? Seems like that path should be known?
>>
>> Would these changes to setup.sh and *.hal need to be applied to files in
>> every config or are these files generated somehow?
>> Point me to the repo and files and I can create the pull requests.
>>
>>
>> On Thu, Nov 2, 2017 at 1:08 AM, Bas de Bruijn  wrote:
>>
>>>
>>>
>>> On 1 Nov 2017, at 21:42, Jerry Trantow  wrote:
>>>
>>> 8) export DEBUG=5 and run MachineKit again.
>>> MACHINEKIT - 0.1
>>> Machine configuration directory is '/home/machinekit/machinekit/c
>>> onfigs/ARM.BeagleBone.Probotix'
>>> Machine configuration file is 'CometNP_Metric.ini'
>>>
>>>
>>> The problem could be this line:
>>> https://github.com/machinekit/machinekit/blob/master/configs
>>> /ARM/BeagleBone/Probotix/CometNP_Metric.ini#L8
>>>
>>> Can you you remove xenomai and try again?
>>>
>>
>>


--
Alexander Rössler
alexander@roessler.systems
+43 680 1348338
Lebnergasse 1/7/7
1210 Wien - Austria
ATU72251528

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Goldibox

[Alexander Rössler]

I have to disagree here.

A PocketBeagle might seem overkill for controlling an ice box - however,
keep in mind that it significantly reduces development cost.

Development cost is a factor of 10 to 1000 more expensive than hardware
costs, especially for one-off and low volume products.

Machinekit is really good for exactly this purpose, it makes it possible
to experiment and tinker in almost no time.

Btw. I have seen IoT hardware for higher prices with less functionality
- 100$ might seem a lot from the tinkerers perspective, but in
professional environment it's nothing compared to the time you are
working on the product.

Keep in mind that prototyping is an important aspect of modern product
development. Want to prove your boss/investors that an ice box can be
controlled with your phone? -  use Machinekit.

John Morris writes:

> [Putting back on list]
>
>
>
> On 11/02/2017 12:21 PM, Chris Albertson wrote:
>  > The reason we don't see Machine Kit used for things like a thermostat is
>  > that would be silly waste of resources.
>  >
>  > If you want to show off Machine kit using it to do something that is 100
>  > time less complex then it's intended purpose is not "showing it off"
>  >   Saing "hey look, this software can used to replace a thermostat is not
>  > interesting"   If you want a non-machine tooldemo that shows off MK then
>  > build a robot with legs that can walk.
>  >
>  > MK makes an even worse IOT demo.  The point of IOT is that you can build
>  > them for i=unde a couple dollars using $100 in parts would look bad.
>  >
>  > So, if the goal is to use MK  then use it to control a machine that is
>  > more complex than an icebox.  If the goal is to build an ice box keep
>  > the control budget under $10 or you look silly using so much over kill
>  >
>  > Perceptions matter.  Using a 64-bit quad core ARM computer to control an
>  > ice box just has "bad optics"
>  >
>  > On Thu, Nov 2, 2017 at 8:25 AM, John Morris   > > wrote:
>  >
>  > [Putting back on list]
>  >
>  > On 11/01/2017 02:30 PM, Chris Albertson wrote:
>  >
>  >
>  >
>  > On Wed, Nov 1, 2017 at 10:50 AM, John Morris   >    > >> wrote:
>  >
>  >  The value IMO is in the demonstration of a full integration
>  > from
>  >  electronics to remote GUI, and in the overall simplicity for
>  >  learners. Maybe it's the lesson that comes after Alex's
>  > AND-Demo.
>  >
>  >
>  > NO, this does NOT demo over all simplicity.  It is very complex
>  > compared to that way this is typically done.This is a
>  > problem that has been solved 100 times already so we cam see
>  >   how others have one it.   OK assuming you want an Phone base
>  > point and click app to control and ice box and you want it to
>  > serve as a demo to show how it is done then at each step you
>  > really should use the "canonical solution".  That is the
>  > cleanest and simplest design at each step. and use the simplest
>  > and easy to understand interfaces between the parts.
>  >
>  > Such a demo would have layers, each layer easy to understand and
>  > the connection between the layers using an simply interfaces.
>  > I'd d it this way
>  >
>  > 1) physical device.  Ice box the Pelitier heat/cooler.   This is
>  > just a Pelteir with a heat sink on both sides,  on heat sink
>  > inside and one outside the box, possible with fans on each.
>  > Then a power supply and the H-bridge.  You also need temperature
>  > sensor(s) inside the box, not mounted to the heat sink
>  >
>  > 2) controller.  connect to temperature sensor(s) and h-bridge
>  > and to control device.It accepts the temperature set point
>  > from the user and reports internal temperature and maybe battery
>  > stays if this is battery powered.You PID controller loop
>  > runs soon this controller. This runs on a tiny micro
>  > controller.   The modern equivalent to the Arduino.This
>  > controller work independently from the use interface because you
>  > don't want to have to runs a computer of cell phone app 24x7 for
>  > something so simple at a temperature controller.
>  >
>  > 3) user interface app.  This runs on a phone or computer,
>  > connects to the above controller, can pull temperature log and
>  > change set point.  It might have nice graphic and maybe can save
>  > data to the cloud.   But then it terminates and lets yto use
>  > computer/phone for other purposes   It would very seriously
>  > consider using a wireless interface from this to #2 above.
>  > Pickone that is already built 

[Machinekit] Re: RTAPI app terminates on startup

[automata]

Hi Cameron,

Thanks for your response. I will be trying the debian jessie rootfs image 
you suggested.

Can you provide any reference on how to copy the kernel modules from your 
custom built kernel to the rootfs.
The kernel I am using is the Xilinx linux-xlnx from petalinux17.02 with the 
Preempt_rt patch.

Awesome work on making the projects independent of Vivado version. Just 
tried your repo with 2017.2. 

So you have any pointers on making and deploying the device tree files. I 
have been trying to understand it for the last two days but have not been 
able to get anything going on the device tree front. Any pointers on what 
to do with the .dts file generated from the 
$carrier/$carrier$config_created/$carrier$config_ol.dts file? That file 
essentially lists the AXI base address in the bitfile design.

Thanks for the awesome work.

Regards,

-automata

On Friday, November 3, 2017 at 1:23:34 AM UTC+5:30, Cameron McQuinn wrote:
>
> Hi automata,
>
> With regards to Linux, I have actually switched from using the ubuntu 
> distribution provided by KRTKL to using a Debian Jessie image that I 
> created myself using qemu-debootstrap. That way, I can just install the 
> pre-built machinekit packages. I followed the instructions on the Debian 
> wiki (
> https://wiki.debian.org/EmDebian/CrossDebootstrap#QEMU.2Fdebootstrap_approach),
>  
> and then installed the kernel modules for my custom-compiled kernel into 
> the rootfs after debootstrap finished. I don't plan on trying to make this 
> work on Ubuntu.
>
> Now to answer your question about Vivado versions. In the TCL scripts for 
> the block diagrams, there is a section that includes the line `set 
> scripts_vivado_version` which checks to make sure that the script is being 
> run in the version of Vivado that generated it. If you remove that section, 
> the script will run in any version of Vivado. The other issue is that 
> Vivado versions after 2015.4 default to using what is called "out of 
> context" builds for the IP, which causes problems when building the hm2 
> firmware_id module because it tries to initialize from a file that lives in 
> the project directory, not the IP directory. To fix this, you have to add 
> some lines to the project template that force Vivado to use a global 
> context when building the IPs. See this 
>  pull request in my 
> personal fork of the mksocfpga repo for details.
>
> Let me know if you have any other questions.
>
> Good luck,
> Cameron
>
> On Thursday, November 2, 2017 at 12:40:34 AM UTC-6, automata wrote:
>>
>> hi Cameron,
>>
>> I posted this on the snickerdoodle group by mistake. Reposting here as 
>> the questions are mainly Machinekit related.
>>
>>  Repost
>> I got the mksoc fpga project for Zturn to build on Vivado 2017.2. I have 
>> also ported the project for Zedboard. I did this by peaking and poking at 
>> the 2015.4 Vivado projects made by JD2 (Many thanks to the-snowwhite and 
>> jd2).
>>
>> Though not being familiar with Xilinx tools or tcl, I dont know how to 
>> generate the tcl project build scripts. I would like to try to get then 
>> done with some guidance. My question is "Is there any plan to account for 
>> the various versions of Vivado in the mksocfpga repository?" For each 
>> Vivado version, do we require a new script to generate the IP wrappers and 
>> other files?
>>
>> I compiled the mksocfpga bitfile and loaded it on the Zturn and Zed 
>> boards with a bare metal application and was able to write to the various 
>> GPIO, LEDs, and hm2_uarts using the memory map in the regmap. Need to try 
>> the encoder and SPI components still. 
>>
>> I am stuck at the linux part. I compiled preempt RT version of the 
>> petalinux kernel supplied by Xilinx. I have put up the instructions for 
>> that here ( https://pastebin.com/Pk04f5At  )
>>
>> Using the instruction here ( 
>> https://medium.com/developments-and-implementations-on-zynq-7000-ap/install-ubuntu-16-04-lts-on-zynq-zc702-using-petalinux-2016-4-e1da902eaff7
>>  ) 
>> I created an Ubuntu root file system image. The only change to the 
>> instructions I made was which particular root file system to use and how to 
>> generate the bit file. I used an Ubuntu 16.04.3 rootfs by rcn from here 
>> https://rcn-ee.com/rootfs/2017-10-12/elinux/ubuntu-16.04.3-console-armhf-2017-10-12.tar.xz
>>  which 
>> includes a C compiler. 
>>
>> However, in this process I lost the ethernet connection on the Zturn 
>> board. Ethernet works during uboot and u boot can get a dhcp IP. But after 
>> the linux kernel boots it does not provide a wired networking interface. My 
>> most likely guess is the device tree is not setup correctly.  I have been 
>> reading about how to use device tree and get the ethernet port working on 
>> the above system.
>>
>> Anyways, Using the C compiler, I compiled a dumb C application that can 
>> write directly to the AXI memory mapped registers for the HM2  offsets