I disagree.   What could be more worthwhile than discussing the merits 
or future possible developments and trends..

Dave

On 6/6/2015 3:32 PM, Rafael wrote:
> Perhaps it's just semantics but we are not making progress here ;-)
>
> On 06/06/2015 05:46 AM, Alexander Rössler wrote:
>> Rafael writes:
>>
>>> On 06/05/2015 01:18 AM, Alexander Rössler wrote:
>>>> Rafael writes:
>>>>
>>>>> On 06/04/2015 07:13 AM, Ron Bean wrote:
>>>>>>> If you need one computer to see the GUI and one for realtime
>>>>>>> effects, why not just start out with a real computer and load Linux and
>>>>>>> LinuxCNC on it?
>>> .... snip
>>>
>>>>> In my HW support experience I came across PDP-11 systems running in
>>>>> steel mills, nuclear and hydro power plants, factories, etc. with little
>>>>> or no graphics. Most used VT100, some used more advanced color
>>>>> terminals. Systems with 32kW(ord) or 64kW RAM controlled huge machinery
>>>>> with RTOS on much slower CPU than we have today.
>>>> The future are distributed systems. Distributed setups are industrial
>>>> standard and are used everywhere from automotive to automation
>>>> industry. CAN and Ethernet are used these days to distribute
>>> neither one is suitable for strict real time.
>> CAN as event triggered bus is not. You may understand TCP/IP as
> Huh???
>
> "BUS" is not event triggered? Every bus I know has an interrupt line(s).
> Generic BUS is just a data path, not an interface, you are mixing the two.
>
>> Ethernet. However, Ethernet can be used as time-triggered bus too. There
>> are many standards such as EtherCAT and Powerlink which are widely used
>> in automation industry.
> But that is not a data bus I'm talking about! Using your definition,
> RS232, parallel port (see, we call it a port), phone line, and
> traditional CaTV network are also a bus.
>
> In my understanding BUS is physical component of a computer to connect
> numerous peripherals to the CPU and among themselves. DMA for example is
> used for data transfer between the peripheral and storage (RAM, disk
> drive, SSD) without CPU intervention. No such thing in ethernet.
>
> All these concepts were resolved on mainframes decades ago. What changed
> is the size of components and their speed.
>
>>>> functionality across different ECUs. The BBB is fine when it comes to
>>>> CAN but an even stronger platform from TI is coming up: the BeagleBoard
>>>> X15 with Gigabit Ethernet support
>>> Don't mix computer BUS and cabling. Two different things. Some cables do
>>> act as traditional extend bus but none at the length of an airplane or
>>> HMMVE.
>>>
>>> What good is Gigabit Ethernet when you need to connect a keypad, a
>>> switch, accelerometer, or optical sensor to BBB? Ethernet is not a bus,
>>> it's one of communications peripherals.
>> You are wrong, Ethernet is a bus. When you take a look at the history
> This is becoming silly. Ethernet IS NOT A computer BUS just like USB,
> RS232, RS485, 60mA current loop, are not traditional data buses. Perhaps
> the terminology got confused when USB was introduced and you know how
> much of a bus that is or how real time that can be.
>
> I work in large data centers and never hear anybody calling ethernet a
> bus. In some instances we use Cat-6 cables, in other we use optical for
> 10Gb or 40Gb connections between the routers, switches and servers. I
> would never call that cheap. A single ethernet interface costs more than
> a large box of BBBs.
>
>> you will see that it started out with a very different physical
>> interface as nowadays. The huge advantage of Ethernet is that network
> I know very well how it started and what kind of connectors were used to
> connect ethernet interfaces on DEC or other computers over the years. At
> some point coax cable was used to string PCs together into a network. I
> probably still have RG-58 cables around, good for amateur radio.
>
> If you forgot 50 ohm terminator, or used a cheap BNC connector, that
> connection went "wireless" and transmitted all over the spectrum except
> between the computers. I paid my share to that hell but we ever called
> it an ethernet BUS!
>
>> hardware is cheap (not all is RT compatible though) because it acts only
>> on the data-link layer (Ethernet frames). What I am talking about are
>> Ethernet hubs.
> I hear "hardware is cheap" all the time. It is in some instances but
> when I ask an engineer that demands additional disk space because he
> thinks hardware is cheap: "if it's cheap, why don't you go out and buy a
> disk drive?" they walk away and start cleaning their home directories
> full of "junk" on servers because management tells them to do so.
>
> Cost is always relative to age, volumes, and features.
>
>> The idea of time-triggered buses is to resend that every
> resend what? Resending packets to fix broken blocks of data is very
> costly. Idea is not to resend anything. Send it once and be done with.
> You cannot afford to lose an interrupt when a mill is at the stop switch.
>
>> cycle. Therefore, a higher network bandwidth means that one can use a
>> smaller cycle time. The bandwidth is not wasted as some people stated.
>>
> Ethernet packet is not guaranteed to make it to the other side, speed is
> not an issue. If you connect only two devices you may get away with it,
> add a switch and you have completely different scenario. And it gets costly!
>
>> Why not attaching the sensors you mentioned directly to the BBB? Just
> Where I've said that? You still need to connect to a board of some kind,
> call it shield or whatever. But ...
>
>> create (or use one of the many) capes with a decent connector and you
>> are fine.
> you seem to completely miss the point. Completely. My original post was
> related to physical awkwardness of "little computers" with non standard
> BUS/connectors/protocol.
>
> It's possible to build interfaces (shields, capes, or whatever other
> silly names they come up with) for any computer if you want to go one
> architecture of a kind but it's costly.
>
> You don't need to go further than
> http://linuxgizmos.com/category/boards/ to see the SBC chaos. Many
> manufacturers don't want to be compatible with a product from another
> company. It's similar situation as "Personal Computers" in the 80's.
> First "personal computers" from DEC were not compatible with HP, IBM,
> ATT, and bunch of others.
>
> Try to find interfaces that you can exchange between "hacker SBCs":
> http://linuxgizmos.com/vote-now-for-your-favorite-hacker-sbcs-maybe-win-one/
>
> This emerging standard is the closest to what I'm talking about:
> http://linuxgizmos.com/new-arm-and-x86-com-standard-gets-a-boost/ but
> the cost is still relatively high. If those who design capes, shields
> etc. made them for a standard like SMARC you would see more affordable
> prices for hackers.
>
> Just in case, computer data bus is not dead:
> http://linuxgizmos.com/arm-based-device-developers-get-smarc-coms/
>
>> If you want to go the industrial standard way you can buy sensors with
>> bus interface (I am not talking about I2C, SPI, ...). Onewire is common
>> for simple sensors. Another example in the automotive industry it is
>> pretty common to have ECUs that do only simple tasks like reading out
>> sensors and providing the data on a CAN bus. With microprocessors
>> getting cheaper and cheaper the industry will further move into
>> distributed systems.
> Again, the discussion was not about what kind of sensors you can buy but
> interfaces and their physical characteristics in relation to specific
> SBCs: Arduino, RaspberryPi, etc.
>
> Go to Maker Faire and you can see many different "little boards" for all
> kinds of things but they are mostly not compatible with each other. But
> they are cheap.
>
>>>> On the other edge of the spectrum we have another low cost solution that
>>>> is currently funded on kickstarter C.H.I.P. a 9$ dollar Linux computer
>>>> with Bluetooth and WLAN => a cheap solution to connect sensors.
>>> This is one of a kind toys that don't make a standard! Nor would anybody
>>> serious use it for a CNC machine.
>>>
>>>> I even heard about things like fly-by-wireless. Which boils down to
>>>> removing the wired buses inside a plane.  So face the facts: Big
>>>> monolithic computer setups will soon be banned to server farms.
>>> Most airplanes and modern military vehicles use computers based on
>>> decades of developments on VME bus and it's derivatives because they
>>> need a lot of connections. That likely includes CompactPCI, it's
>>> emerging CompactPCI Serial, and VPX.
>>>
>>> As tiny lasers are getting cheaper, cost of building optical bus and
>>> compatible peripherals will become more common in the near future so
>>> we'll see even more data buses.
>> Optical cables have different problems than metal cables. They have more
>> problems when it comes to mechanical stress. I am not sure they will
>> succeed copper wires that quickly.
> I'm working with optical cables on a daily basis for some time now.
> Again, you don't understand what an optical bus is, it is not a cable,
> which you seem to mix every time subject of data bus is coming up.
> Ethernet over optical lines is not a bus.
>
>> When you take a look inside an airplane you will see that the wiring is
>> consuming a lot of space inside the hull. The idea of replacing some
>> buses with wireless interfaces drastically reduces development costs. So
>> maybe in 30-50 years we will have wireless operating planes.
> On my tour at Boeing I learned that wiring is not one of the major problems.
>
> Wireless is not magic to solve all of your wiring problems. Radio will
> never replace wiring in "mission critical systems". Airplane is one of
> them. Man, that would be simple way to get airplanes off the sky!
>
>>> Every computer in existence has a bus, available or not, for connections
>>> to additional peripherals. There is a bus on BBB, RaspberryPi, Radxa,
>>> and other little SBCs to add peripherals. My comment was about the
>>> problem with every little SBC having different connectors and their
>>> positions on the board while all are using "sandwich mechanical
>>> architecture" that cannot be expanded easily.
>> What you are pointing out is that these devices do not come with
>> standard connectors. There are some capes (additional board that can be
>> put on the pin headers) that provide different connectors for different
>> applications. The BeagleBone Green will come with connectors for the
>> Groove sensors if you want something out of the box. Furthermore, you
>> have USB and Ethernet connectors available.
> Can you use Arduino ethernet card on BBB? Can you use wireless card from
> one platform on another? No and that's my problem.
>
>> However, I agree that connectors are a big problem in general when it
>> comes to computers. Only few capes address this problem an come with pin
>> headers to connect sensors/motors. However, that is one problem we tried
>> to address with the SandyBox and the different controller boxes
>> (Lin-Ctrl stepper driver, Print-Ctrl for the 3D printer) . They come
>> with standard Molex connectors to connect sensors, switches an motors.
> It's here that makes me think that you are involved in SandyBox design
> or production. Good for you. It's open discussions like this that can
> make a big difference even though we strayed into computer history,
> production, etc.
>
> I never commented on SandyBox specifically. My comment (again) was
> related to lack of standards for hobby or DIY makers. That's all.
>
>> We are planning a future version of the SandyBox to address this
>> problem. So if you have ideas please share them.
> I'm glad to see somebody design a box that serves it's purpose
> especially if it's able to run Linux. If I understand the description
> correctly, it's specifically targeting (CNC) systems that use parallel
> port. There are other options for different CNC machines too many to
> list them here.
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


------------------------------------------------------------------------------
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to