Re: [Emc-users] Adding an RS485 interface [Was: Re: about to give up on the pi's]

2017-05-07 Thread Gene Heskett 
On Friday 05 May 2017 17:47:05 Gene Heskett wrote:

> On Friday 05 May 2017 11:45:49 andy pugh wrote:
> > On 5 May 2017 at 15:52, Gene Heskett  wrote:
> > > Since this stuff is best described as volatile, I'll buy the 5
> > > pack so I've some to  "play with".
> >
> > What do you intend to do with this RS485 interface?
>
> I don't know yet Andy. Gotta see what it can do speedwise first.
>
> Cheers, Gene Heskett

Well, plugged into a usb port on that old slow sheldon, I get rise and 
fall times of the A signal out in the 16ns area.  And I'll have to plead 
oldtimers because I could not remember the name of the serial port 
config daemon, stty, which is currently doing 9600 baud.  Now to go back 
out and see how fast I can make it run. Back eventually.

It seems that "stty -F /dev/ttyUSB0 460800" still sends pretty well 
defined data, which my scope says is a red hair over 2 us for character 
time, and inverts that to 460.2 kilo baud.

Now, the cat5 socket on the 7i90 is an 8 line, even POE, full duplex, A&B 
send and separate A&B rx.  Since all these so-called adaptors are only 3 
wire half-duplex, and assuming the use of a regular db9 serial port 
with "7 wire protocol which is full duplex", is there anyone making a 
plug and play, using 2 of these adaptors, gizmo that just works?

My attempt to make a new card for the pi, ends up with exactly the same 
error. Thats 5 passes at recovering what was working quite well the 
morning of 2 May. No one can believe me that the 13 file update done 
later that morning, bricks the pi's.

I'm very impressed with the lack of data on the up-shop.net web site as 
to just what these atom powered things have, they don't even say how 
wide the gpio count is, so I may have bought a very lightweight 
paperweight, but the card was accepted for one just like Erik said he 
had bought. 2 gigs of ram, 16gigs of eMMC for a disk drive. $124 
shipped.  With suitable drivers, all running x86/intel code, its 
promising.  The forum is loaded with this and that don't work messages 
though. I don't see a debian for downloading but I'd prefer it, jessie 
is close to EOL, and rumors are saying stretch is fairly stable now.  
Theres some sort of a ubuntu I never heard of, yocto (whats that?) and 
whatever is running the fawncy phones these days.

Cheers all;  Gotta hit the grocery store.  Out of eggs.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] about to give up on the pi's

2017-05-07 Thread Gene Heskett 
On Friday 05 May 2017 17:43:16 Gene Heskett wrote:

> On Friday 05 May 2017 09:25:01 Charles Steinkuehler wrote:
> > On 5/5/2017 7:56 AM, andy pugh wrote:
> > > On 5 May 2017 at 13:41, Charles Steinkuehler
>
>  wrote:
> > >> So does the armhf build run in Raspian or are you using qemu or
> > >> something?  AFAIK, standard Debian armhf code won't run on the
> > >> RPi because Raspbian uses a different ABI (due to the not-quite
> > >> full armhf compatible CPU on the original RPi).
> > >
> > > It might be worth considering that Gene's experience seems to be
> > > that LinuxCNC on the Pi runs less than flawlessly.
> >
> > Indeed.  I've only just started playing with the RPi3 and have
> > already hit some issues.  I was hoping the GPU would be usable, but
> > it looks like there are still problems.  I think the BBB (or an
> > SoC+FPGA) is probably a better choice if you don't need a native
> > GUI, and if you _do_ want a GUI a low-end x86 box is likely a much
> > better choice.
> >
> > I've ordered one of these x86 SBCs to play with and see if I can get
> > it talking to Mesa hardware via SPI:
> >
> > http://up-shop.org/up-boards/2-up-board-2gb-16-gb-emmc-memory.html
>
> That looks like a raspi killer, but whats an eMMC memory, because I
> sure don't see a socket for a micro-sd card.
>
> > ...if it works out, it may be a good midway point between the ARM
> > based SBCs and a full x86 machine.
>
> I agree, except for the system memory.
>
> Soldered to the board flash memory bothers me, a lot.  If it didn't, I
> would have used my card to put some postage on its even better equipt
> 4Gb dram and 32Gb of e-MMC. I have 2 of the original D525MW boards,
> one of them is still software stepping a 4 axis micro-mill. Not fast,
> but fast enough to get the job done.
>
> > > https://wiki.debian.org/RaspberryPi
> > >
> > > Seems to suggest that armhf works on Pi >= 2.0
> > >
> > > buildbot "sim" builds run with realtime on preempt-rt kernels.

Unfortunately, the buildbot has been unreachable since my problems began.
I have stripped my sources.lists down to just the buildbot:
deb http://buildbot.linuxcnc.org/ jessie master-sim
deb-src http://buildbot.linuxcnc.org/ jessie master-sim

 but sudo apt update returns:

Err http://buildbot.linuxcnc.org jessie InRelease
  
Err http://buildbot.linuxcnc.org jessie Release.gpg
  Could not resolve 'buildbot.linuxcnc.org'
Reading package lists... Done
Building dependency tree   
Reading state information... Done
All packages are up to date.
W: Failed to fetch http://buildbot.linuxcnc.org/dists/jessie/InRelease  

W: Failed to fetch http://buildbot.linuxcnc.org/dists/jessie/Release.gpg  
Could not resolve 'buildbot.linuxcnc.org'

W: Some index files failed to download. They have been ignored, or old 
ones used instead.

The web page is there at buildbot from this machine, but Damn if 
network-mangler hasn't re-written the /etc/resolv.conf with a blank 
file. First is nuke resolvconf, rewrite a good /etc/resolv.conf, make 
sure it works and sudo chattr +i /etc/resolv.conf. Done. Now the 
buildbot responds and tells me linuxcnc is all up to date.

> >
> > Yeah, I should be able to use the armhf builds if I'm running stock
> > Debian (which works on the RPi 2 & 3).  I started with Raspbian to
> > see what the "out-of-the-box" experience is like, and figure it's
> > unlikely I can tweak Debian to work better than Raspbian.  I'm
> > unclear what Gene's running, but I'm guessing it's Debian armhf
> > rather than Raspbian.
>
> Cheers, Gene Heskett


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Emc-users Digest, Vol 133, Issue 18

2017-05-07 Thread TJoseph Powderly 
On 05/07/17 21:33, Tim wrote:
> I have been playing with RPI for some time now trying to get 
> Hal2Arduino working for a multi-task hobby cnc that I have built. Have 
> software working for xyza axis still need to hook up drivers and 
> steppers. I know that linuxcnc is not going to work as well as what 
> Gene Haskett is doing but this is a hobby machine. Still having 
> trouble getting xyuv axis part of machine working have a config file 
> error to figure out.
> But the reason why I responded to this post I have instructions on 
> how to create a minimal install for RPI image that will work on RPI2 
> or 3. Seems it could help allot of people, so here it is.
>
>
> Follow these direction in order to make a minamal Raspbian "Debian 
> Jessie" install
> with a realtime kernel,(ver. 4.4.9-rt17) and Mate Desktop and Linuxcnc
> sdcard will work with rpi2 or 3
>
> Download Emlid image for sd card then extract from
> https://files.emlid.com/images/emlid-raspbian-20160718.img.xz 
> ..

thanks!

i was just looking at emlid and found the forward references a dead end

and was thinking... 'will the last image work?'

tomp tjtr33


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] [emc-users] Building from source

2017-05-07 Thread Sebastian Kuzminsky 
On 05/07/2017 07:09 AM, suavesteve wrote:
> I've come across this earlier and had created a local patch,
>
> Tested with both v3.0.6 and v3.1.4 (Latest Stable release)

Thanks Philip/suavesteve for posting that!

It's strange to me that the libmodbus folks went from using a struct 
timeval for their timeout to passing the fields individually, but sure 
enough they did.

According to http://libmodbus.org, 3.0 is stable and 3.1 is still listed 
as unstable, even though it's been around for years and has had several 
stable-looking "releases".

Some feedback on your patch:

You pass timeout.tv_sec for both the seconds and the microseconds, I 
think you meant to pass timeout.tv_usec for the third argument.  Details 
on that here: 
http://libmodbus.org/docs/v3.1.4/modbus_set_response_timeout.html

Instead of taking the pointer of timeout and dereferencing it 
("(uint32_t) (&timeout)->tv_sec"), it's simpler and clearer to just use 
the field directly ("(uint32_t)timeout.tv_sec").

There's a bug in the #if you use for version detection, think about (for 
example) a hypothetical future version 4.0.  Use LIBMODBUS_VERSION_HEX 
instead of LIBMODBUS_VERSION_MAJOR and LIBMODBUS_VERSION_MINOR.  Instead 
of this:

+#if LIBMODBUS_VERSION_MAJOR >= 3 && LIBMODBUS_VERSION_MINOR >= 1

Use this (untested):

+#if LIBMODBUS_VERSION_HEX >= 0x0301


If you make those changes, and sign off on your commit (see 
http://linuxcnc.org/docs/devel/html/code/contributing-to-linuxcnc.html#_signed_off_by_policy),
 
then I'll gladly apply your patch in LinuxCNC 2.7.


-- 
Sebastian Kuzminsky

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Emc-users Digest, Vol 133, Issue 18

2017-05-07 Thread Tim 

I have been playing with RPI for some time now trying to get Hal2Arduino 
working for a multi-task hobby cnc that I have built. Have software working for 
xyza axis still need to hook up drivers and steppers. I know that linuxcnc is 
not going to work as well as what Gene Haskett is doing but this is a hobby 
machine. Still having trouble getting xyuv axis part of machine working have a 
config file error to figure out.
But the reason why I responded to this post I have instructions on how 
to create a minimal install for RPI image that will work on RPI2 or 3. Seems it 
could help allot of people, so here it is.


Follow these direction in order to make a minamal Raspbian "Debian Jessie" 
install
with a realtime kernel,(ver. 4.4.9-rt17) and Mate Desktop and Linuxcnc
sdcard will work with rpi2 or 3

Download Emlid image for sd card then extract from
https://files.emlid.com/images/emlid-raspbian-20160718.img.xz

# On Linux computer download Etcher to write image to sdcard at

https://etcher.io/

Download, extract and run Etcher
Select the archive file with image and sd card drive letter.
Click “Flash!”. The process may take a few minutes.

--

# RT-PREEMPT realtime kernel
# Download kernel image
 
http://download.frank-durr.de/kernel-4.4.9-rt17.tgz


# Extract files
# Start your file manager from terminal with root privliges, my file manager is 
thunar so I use:
# sudo thunar
# Copy extracted files inside boot directory, to boot directory on sdcard 
choose to overwrite files
# Copy extarcted file lib, to root of other partition on sdcard choose to 
overwrite files

---

# Install Sdcard into PI
# Connect to wired network
# Or shh from another computers ethernet connection



# See posts at this site about rt patched kernel on pi2 & 3 freezing during 
wifi use

https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=159170

# Need to add to end of cmdline.txt

sudo nano /boot/cmdline.txt

#Add the following

dwc_otg.fiq_fsm_enable=0 dwc_otg.fiq_enable=0 dwc_otg.nak_holdoff=0

sudo reboot -n

-

# Update to correct keyboard layout

sudo dpkg-reconfigure keyboard-configuration

-

# Generate locales

sudo dpkg-reconfigure locales
#add correct language
en_US.UTF-8
locale -a
#To check locale

---

#Update Time Zone

sudo dpkg-reconfigure tzdata



sudo raspi-config
#NOTE: do not Overclock
1 Expand File system
  when finished choose to reboot
If you need other things enabled such as SPI or C12 ect. it can be done here
--

sudo apt-get -y update && sudo apt-get -y upgrade



# RPI 2 or 3
sudo apt-get install -y mate-core mate-desktop-environment xorg lightdm
sudo apt-get install -y network-manager-gnome synaptic iceweasel xterm

# RPI 3
sudo apt-get install -y pi-bluetooth
sudo apt-get install -y bluetooth bluez blueman

---

#Setup network manager

sudo nano /etc/network/interfaces
#Comment out
#iface wlan0 inet dhcp
#iface default inet dhcp
#iface wlan1 inet dhcp
#iface eth0 inet manual
# Use control key and x to save and save to default

-

#Update rpi firmware without over writing rt kernel

sudo apt-get install rpi-update
sudo SKIP_KERNEL=1 rpi-update

sudo reboot -n



#Install Linuxcnc

On RPI goto web page
http://buildbot.linuxcnc.org/
Follow directions to install 2.7 or Master, Jessie (uspace: realtime with 
RT-Preempt, and simulation), armhf
# first add repository key, open Mate Terminal look for it in system tools menu 
item, you can copy and paste from web site page:

sudo apt-key adv --keyserver hkp://keys.gnupg.net --recv-key E0EE663E

# Start text editor Pluma with root privliges like this:

sudo pluma /etc/apt/sources.list.d/linuxcnc-buildbot.list

#Add the following to file for 2.7 then save:

deb http://buildbot.linuxcnc.org/ jessie 2.7-sim
deb-src http://buildbot.linuxcnc.org/ jessie 2.7-sim

# Now update the system:

sudo apt-get update

# Now start Synaptic which will only start from terminal

sudo synaptic

# Type in

Re: [Emc-users] [emc-users] Building from source

2017-05-07 Thread suavesteve 
I've come across this earlier and had created a local patch,

Tested with both v3.0.6 and v3.1.4 (Latest Stable release)

>From 0b557f7116cd52a2b69e84872588e22577c1b459 Mon Sep 17 00:00:00 2001
From: Philip Mullen 
Date: Sun, 7 May 2017 13:52:53 +0100
Subject: [PATCH] Add support for libmodbus >= v3.1

Added support for the new form of modbus_set_response_timeout
and modbus_set_byte_timeout in versions >= 3.1
---
 src/hal/user_comps/mb2hal/mb2hal.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/src/hal/user_comps/mb2hal/mb2hal.c b/src/hal/user_comps/mb2hal/mb2hal.c
index 1ba9a87..1ca067e 100644
--- a/src/hal/user_comps/mb2hal/mb2hal.c
+++ b/src/hal/user_comps/mb2hal/mb2hal.c
@@ -355,18 +355,28 @@ retCode get_tx_connection(const int this_mb_tx_num, int *ret_connected)
 
 //set the low level mb_link debug according to each mb_tx
 modbus_set_debug(this_mb_link->modbus, this_mb_tx->protocol_debug);
-
-//set response and byte timeout according to each mb_tx
 timeout.tv_sec  = this_mb_tx->mb_response_timeout_ms / 1000;
 timeout.tv_usec = (this_mb_tx->mb_response_timeout_ms % 1000) * 1000;
-modbus_set_response_timeout(this_mb_link->modbus, &timeout);
+//set response and byte timeout according to each mb_tx
+#if LIBMODBUS_VERSION_MAJOR >= 3 && LIBMODBUS_VERSION_MINOR >= 1
+modbus_set_response_timeout(this_mb_link->modbus, (uint32_t) (&timeout)->tv_sec, (uint32_t) (&timeout)->tv_sec);
+#else
+modbus_set_response_timeout(this_mb_link->modbus, &timeout);
+#endif // LIBMODBUS_VERSION
+
 //DBG(this_mb_tx->cfg_debug, "mb_tx_num[%d] mb_links[%d] response timeout [%d] ([%d] [%d])",
 //this_mb_tx_num, this_mb_tx->mb_link_num, this_mb_tx->mb_response_timeout_ms,
 //(int) timeout.tv_sec, (int) timeout.tv_usec);
 
 timeout.tv_sec  = this_mb_tx->mb_byte_timeout_ms / 1000;
 timeout.tv_usec = (this_mb_tx->mb_byte_timeout_ms % 1000) * 1000;
-modbus_set_byte_timeout(this_mb_link->modbus, &timeout);
+
+#if LIBMODBUS_VERSION_MAJOR >= 3 && LIBMODBUS_VERSION_MINOR >= 1
+modbus_set_byte_timeout(this_mb_link->modbus, (uint32_t) (&timeout)->tv_sec, (uint32_t) (&timeout)->tv_sec);
+#else
+modbus_set_byte_timeout(this_mb_link->modbus, &timeout);
+#endif // LIBMODBUS_VERSION
+
 //DBG(this_mb_tx->cfg_debug, "mb_tx_num[%d] mb_links[%d] byte timeout [%d] ([%d] [%d])",
 //this_mb_tx_num, this_mb_tx->mb_link_num, this_mb_tx->mb_byte_timeout_ms,
 //(int) timeout.tv_sec, (int) timeout.tv_usec);
-- 
2.9.3


Philip

Evan Foss  writes:

> Is anyone looking into this?
>
> On Thu, Apr 27, 2017 at 3:49 AM, Evan Foss  wrote:
>> On Wed, Apr 26, 2017 at 1:30 PM, Sebastian Kuzminsky  
>> wrote:
>>> 2.7 should build anywhere the master branch (2.8-prerelease) builds, what
>>> build error do you get?
>>
>> Attached are the configure and build runs. I tried playing with the
>> --enable-non-distributable=yes option but it still lands on the same
>> error.
>> This is just the error extracted from the build.
>>
>> Compiling hal/user_comps/mb2hal/mb2hal.c
>> hal/user_comps/mb2hal/mb2hal.c: In function ‘get_tx_connection’:
>> hal/user_comps/mb2hal/mb2hal.c:362:5: warning: passing argument 2 of
>> ‘modbus_set_response_timeout’ makes integer from pointer without a
>> cast [enabled by default]
>> In file included from hal/user_comps/mb2hal/mb2hal.h:18:0,
>>  from hal/user_comps/mb2hal/mb2hal.c:27:
>> /usr/include/modbus/modbus.h:188:16: note: expected ‘uint32_t’ but
>> argument is of type ‘struct timeval *’
>> hal/user_comps/mb2hal/mb2hal.c:362:5: error: too few arguments to
>> function ‘modbus_set_response_timeout’
>> In file included from hal/user_comps/mb2hal/mb2hal.h:18:0,
>>  from hal/user_comps/mb2hal/mb2hal.c:27:
>> /usr/include/modbus/modbus.h:188:16: note: declared here
>> hal/user_comps/mb2hal/mb2hal.c:369:5: warning: passing argument 2 of
>> ‘modbus_set_byte_timeout’ makes integer from pointer without a cast
>> [enabled by default]
>> In file included from hal/user_comps/mb2hal/mb2hal.h:18:0,
>>  from hal/user_comps/mb2hal/mb2hal.c:27:
>> /usr/include/modbus/modbus.h:191:16: note: expected ‘uint32_t’ but
>> argument is of type ‘struct timeval *’
>> hal/user_comps/mb2hal/mb2hal.c:369:5: error: too few arguments to
>> function ‘modbus_set_byte_timeout’
>> In file included from hal/user_comps/mb2hal/mb2hal.h:18:0,
>>  from hal/user_comps/mb2hal/mb2hal.c:27:
>> /usr/include/modbus/modbus.h:191:16: note: declared here
>> make: *** [Makefile:211: objects/hal/user_comps/mb2hal/mb2hal.o] Error 1
>>
>>
>>> And how does matter fail to run?
>>
>> 2.8-prerelease has some quirks you should know. (or perhaps i am miss using 
>> it)
>> 1. It doesn't understand --prefix= as other packages seem too in my
>> experience. When I went to do make install it complained about not
>> having a DESTDIR so I added DESTDIR :=  / to the Makefile.
>>