|
Cockmaster posted:How well do you suppose the Pi would handle SDLMAME? I was thinking it'd be cool to build a miniature arcade cabinet and stick one in, kind of like Coleco's tabletop arcade games from the early 1980's. The problem isn't that an ARM can't do real time computing, it can. The problem is that most OS aren't designed with real time computing in mind. Few modern OS are designed around having hard and exact timings of output, they tend to optimize for speed and throughput instead. This include most Linux distributions, like those that the Pi comes with. Your idea of having the board run just CNC software (without a host os. no matter how stripped down, linux is not hard real time) is one solution. Dedicated ARM boards have been developed for interpreting CNC g-code (here's one for reading g-code for a 3d printer). But wait, you say, you can do linux hosted CNC machines with programs like EMC2. You'd be right. This is because EMC2 has runs under a variant of linux that has real time computing extensions. (It does this in a quite clever way, the entirety of linux is setup as a fully preemptive process.) Of course, there is no version for raspberry pi yet.
|
#
¿
Apr 17, 2012 04:10
|
|
|
|
| # ¿ May 20, 2024 17:50 |
|
|
Tim Thomas posted:To be frank, if you're looking for anything reasonably accurate, you're probably better off buying a refurbished Galil or Delta Tau system off Ebay. Once you factor in the cost of the amplifier, a UMAC with a 4 axis controller and quad amp will satisfy almost every home CNC setup, unless you somehow have a 5 axis in your home. I'm all for learning and making things work, but there's a good reason that CNC stuff is written at a really low level, and I really don't see the point of hacking and bashing a kludged setup when you can buy a refurb UMAC and learn motion PLCs and g-code on the same setup that thousands of machines are running on. Most home CNC stuff isn't a based on a kludged together setup of an amplifier and a UMAC and a PC. It's done with a dedicated motor driver board plugged into a parallel port on an old pc running a gcode interpreter. (TurboCNC, Mach3, EMC2, KCAM, etc) It's quite well tested and works very well. Typically the limiting factor is not the software, but the fact that a home cnc setup doesn't have the rigidity of a professional machine. In addition, if you already know how to use a computer well, it's easy. I guess the fundamental question is that I don't really know what you mean by "anything reasonably accurate." What I can say is that this kind of computer and driver board are often in the area of .01mm. Depending on your application this can be plenty accurate to no where near accurate. I'd say for most hobbyist class engineering its more than enough. One problem with using the Raspberry Pi in this kind of setup is that it doesn't have a parallel port. Instead you could use its GPIO to communicate with the driver board. Another problem is that there's no RTLinux or RTAI port for the Pi. The boards simply hasn't been in the hands of the people who would make such a port long enough. spog posted:I took at look at the last 5 pages: they do mention Arduinos, but only in passing. There's also the Embedded programming nanothread. You'd think a thread for Small Microcontroller Projects would be a good idea, but the last one fell into the archives. The electronics megathread is your best bet. Much of the anti-arduino stuff in it is terminology based. The arduino isn't a microcontroller, it's a platform.  There are other (small) things, but that word choice gets things off on the wrong foot.To answer your question though, do you have the majority of the following: a breadboard potentiometers resistors leds photocell If you have these things, a starter kit doesn't really give you much in the way of advantages, but if you don't, it's really good. If what your missing though is the breadboard just buy a starter kit, it's not a bad deal and you do want a breadboard.
|
|
#
¿
Apr 17, 2012 17:39
|
|
|
WALLS OF TEXT!peepsalot posted:Raspberry PI GPIO shortage. Interestingly enough, at this point I've argued on both sides of this issue. This is the main issue with using the Pi to control real stuff. It also has a nice real solution. The Raspberry Pi conveniently exposes it's SPI and I2C busses, as well as a UART. Connect GPIO expander chip(s) to any of them and you'll have all the IO you'll ever need. Here's some people who've designed a stackable one, stack them to the heavens(8 of them) and get an additional 128 GPIO. Unfortunately, there isn't enough gpio pins to just emulate a parallel port and just use the current CNC driver boards, so no matter what you want, you're talking about adding additional custom hardware. spog posted:Stuff about kits and clones. Clones are fine, they just don't give money to the people who designed the arduino. If you buy a setup without an assortment of individual parts just go to a local electronic parts store, and buy a few of the common things that you see in most kits. A photocell, a few momentary switches, some 10k potentiometers, leds, 10k resistors for pullup/pulldown (or use microcontroller's internal ones), leds, 150 ohm resistors for leds (a good standard size, not optimal for all colors, but safe and effective at 5v. learn to size them later) would get you started. None of those jumped out at me as a bad deal. Tim Thomas posted:I guess this is my point: with CNC, if you can use honest-to-god real hardware (a UMAC+Amp+PC isn't really kludgy, it's an integrated setup that runs a whole boatload of machine tools) at a minimal price delta from hacking and bashing, why wouldn't you go that route and gain real experience with something that translates to how things work in the real world? It's one thing if we're talking steppers and a small set of leadscrews or what have you, but what happens when you want to do something bigger? Sorry I misunderstood what you meant by kludgy, it was unclear by your wording which you were referring to. Partially because I'm not familiar with the industrial tool chain and you named off interfacing 4 devices in a row, and partially because a PC and a driver board isn't a kludge at this point. As far as why wouldn't I use industrial tools? Basically three reasons jump to mind. One, from a quick ebaying, the low side of industrial equipment is over twice as expensive as the high side driver boards. Two, there really aren't physical benefits to using the cheap ones, while more expensive setups have direct benefits they cost yet more. Three, I'm not trying to get an industry job, what they do simply doesn't impact me. PLC experience won't matter for any job I'm going for. Even if I was, I'll still be learning things like design for manufacturing, CAM software, G-code, and so forth. As far as your other question, how big is big? Hobbyist CNC machines are huge at 4x8 foot router table, and they only ever get that large if people want to do whole pieces of sheet goods. The next biggest thing is typically a bridgeport cnc conversion. Tim Thomas posted:Don't get me wrong, I built amp drives and PID controllers in college to learn theory, and I recognize the value in really knowing the hardware and theory end of how motion control works, but ultimately, I feel I would have been better off learning PMAC or Galil or what have you earlier instead of trying to reinvent the wheel myself. Part of this is also because I'm less interested in CNC and more interested in machine automation. The things is though, it isn't reinventing the wheel for most people. It's loading a piece of software, and plugging in a device, and there, now you have a working CNC controller, for less than $100. On the topic of general automation, the short version is that you're correct in that these programs are special purpose enough that they wouldn't really be suitable. If you're doing non-cnc work, it won't help you and you would end up reinventing it all. I still have concerns about cost/benefit of professional gear, but that's incredibly rooted in exact applications. Tim Thomas posted:You're ultimately limited by how good your control loop, tuning, deadband, and encoder are, but there's a ton of really neat and absurdly inexpensive encoders that have come on the market that are beyond the capabilities of any hobbyist stuff I've seen. This is less CNC and more general automation, but the fact that I can buy a brand new nanometer encoder for about a thousand bucks all in means that I can build production-worthy metrology on the cheap. Not something a home hobbyist needs by any means, but it means that as an experimenter or a person investigating startup ideas, I have the latitude to try things I may not be able to with a homebrew setup. That kind of side steps the question. What is reasonably accurate? It depends on the application. For the majority of applications .01mm is beyond what is needed. A typical pair easily accessible and cheap digital calipers is only accurate to .005mm anyway (if that), so adding additional accuracy to a machine quickly outstrips what you can actually verify. Calling a $1000 encoder cheap boggles me(I'm sure it is for its capabilities are, but none I've ever bothered with was more than $10, and $100 would have been horrifically expensive), but if it has a standard encoder signal, both Mach3 or EMC2 could read it anyway. They both can also do PID controls. On the topic of interfacing with industrial equipment, they can also interface with industrial servos. I've seen home built cnc stuff with yaskawa servopaks. Again though, this is if you're doing odd cnc work, for general automation using this is much more questionable. Tim Thomas posted:In fairness, a lot of this comes from the fact that I get to use a lot of this in my line of work, and having to go from the automation tools I use at work to having to reinvent them would annoy me well beyond the point that I'd go do something else instead of play with motors. By all means, use what you're familiar with. Knowing a system is always huge. I know computers, not industrial equipment. Desktop CNC software and driver boards let me do it easily, cheaply, and good enough for anything I've wanted. Is the performance ceiling lower? Quite possibly, but is it problematically lower? All that said, you did say a few times that you were interested in automation beyond cnc. For that, yes, I can easily believe that much of this industrial equipment is vastly more suitable than programs designed for a single purpose. I can even speak with experience here, there's a project that has mach3 running as the host program for 3d printing. It's piles of kludges and additional external hardware for what looks like, on the surface at least, a very similar problem domain. I've tried to keep any negativity from my responses as it sounds like you're doing some fascinating stuff. We're treading a bit close to off topic, so do you have it posted anywhere else? There's the robotics thread in DIY and hobbies.
|
|
#
¿
Apr 19, 2012 07:40
|
|
|
peepsalot posted:So basically what I'm getting at is that if it is possible to make a daughterboard for raspi that can break out enough pins over i2c or whatever to perform similar function as RAMPS, for similar price, then that could possibly make quite a few people happy. The whole intermediate parallel interface idea is foreign to me, and seems extraneous. For running something like a reprap where they've basically always had the freedom to grow their own hardware exactly as they want it, an intermediate (and captive) parallel interface would be totally extraneous. Repraps grew up around cheap micro controllers with lots of GPIO. On the other hand, hobbyist cnc machines grew up around x86 PCs with very little GPIO, the only standard and easy to get at IO is on a parallel port. As such the motor driver boards are parallel based.(example) For using a Raspberry Pi as a cnc controller, it would have been nice to be able to plug one of these in, and just run LinuxCNC(EMC2) like you would any other pc. But a RPi doesn't have a parallel port, and there isn't enough GPIO to emulate one either. So you'd need either a different hardware driver, or a glue layer of hardware between the RPi and a standard driver. Each way would have pretty similar hardware of a few GPIO expanders. Software complexity would be pretty close too, either way you need to say which signals go to which pins. If you're doing an integrated solution with all new hardware, I'd take the same approach of just I2C or SPI interface and not emulating a parallel port, just to have a conceptually cleaner design. By doing a separate glue hardware layer you get the choice of standard driver boards. Back to reprap. Instead of a RAMPS (Reprap Arduino Mega Pololu Shield), we'll probably soon get a RRPPS (Reprap Raspberry Pi Pololu Sheild). Although, since shield is a arduino term we'll end up with RRPPDB instead.
|
|
#
¿
Apr 20, 2012 07:16
|
|
|
Cockmaster posted:If you're going to go that route, you'd probably be better off with the BeagleBone, which was actually designed for stackable expansion boards (called capes). Plus it has 66 GPIO pins, more than enough for even a relatively fancy machine. On the plus side, the BeagleBone is designed for stackable expansion boards, has much more native GPIO, and you can buy and get one now. All excellent points. On the minus side, it's $90. Over 2-3x the price of a Raspberry Pi (depending on model). Of course the RPi doesn't have enough GPIO to do GPIO heavy stuff stuff, like a reprap board. You'd need to include expander chips as part of the new daughter board to make it a single board solution. To bring the RPi up to parity with the BeagleBone, we'd be talking around 4 16 channel chips, for an additional 64 GPIO. The most expensive expanders I've found are less than 3 dollars a chip, and many are less than $1. So, the cost of saving 55+ dollars on the controller is making the daughter board 4-12 dollars more expensive. If they use the 3 dollar expander chips, you'd have to buy 5 daughter boards worth of redundant hardware to even out, and if they use the cheap ones, you're talking more than a dozen sets. Now then, I'm not really familiar with the BeagleBone so it may well have yet other advantages that I can't see from a cursory glance. The extraordinarily low cost of the RPi puts a massive squeeze on other ARM boards, but it's also bound up with supply issues and the added difficulty of needing external expanders. It'll be interesting seeing how it all interacts. Aurium fucked around with this message at 09:04 on Apr 27, 2012 |
|
#
¿
Apr 27, 2012 08:57
|
|
|
thelightguy posted:I'm still waiting for mine to arrive, but I'm curious how hard it is to interface with the I2C bus. I found a bunch of low-cost 16 channel LED drivers that use I2C for control, and would love if they have basic "send 'blah' to 'address'" drivers so I could do all the work in userland without having to write any kernel-mode drivers. Even without device specific drivers, it's not too hard to do everything in userland. https://github.com/raspberrypi/linux/blob/rpi-patches/Documentation/i2c/dev-interface
|
|
#
¿
May 25, 2012 19:11
|
|
|
Cockmaster posted:Do you suppose it's be possible to use the Raspberry Pi to run the standard Reprap software? It already relies on an external motion controller (Arduino Mega), so real-time programming wouldn't be an issue. It wouldn't be as cool as programming an ARM board to run the machine by itself, but it could be worthwhile for many applications. In all likelihood any of the linux reprap host software will run on a RPi without modification. One note I would like to make is that slicing/tool pathing/gcode generation step is rather processor intensive. It's still be very likely to run unchanged, it'd just be slow on the not so powerful ARM in the RPi. Feeding the printer already generated gcode would be well within its capabilities.
|
|
#
¿
Jun 7, 2012 04:04
|
|
|
keyvin posted:I am interested in messing around with the gpio pins. But I need to know one thing first. If you screw up the voltage and accidentally send five volts, would I have to buy a new pi? They aren't 5V tolerant. So they'll probably be damaged by such a mistake. If you only expose them for a short time, or by a low current source, it is possible that they may not be damaged but this is not at all guaranteed. Exactly what will happen will depend on the state of the pins, the exact physical construction and layout of the chip, and other such details. Even if you experiment and find an overvoltage setup that works for your purposes, this kind of damage is often cumulative, so just because it works now, doesn't mean it will stay working. The good news is that the damage is often limited to the GPIO pin you expose, rather than the entire chip.
|
|
#
¿
Mar 7, 2013 05:39
|
|
|
ratbert90 posted:No. 5v is what the thing runs off of, and unless the gpio pins are tied directly into the CPU (more than likely 3.3v) You will be fine connecting a 5v source to the pi. I would look at the schematics though to make sure you aren't doing anything stupid like plugging a 5v power source into a 3.3 pin. They do connect directly to the 3.3v cpu. There is no overvolt protection on the board. schematic documentation HATE TROLL TIM posted:Okay, can someone clarify GPIO voltage tolerance for me? I keep seeing people say the GPIO is 3v3 only and to never, ever hook 5v up to it or it'll explode. That completely contradicts my experience with it so far. All your missing is how semiconductors die. If the voltage difference isn't enough to just destroy it right out (by punching though oxide layers and similar) most destruction is caused by overcurrent. Overcurrent generally kills though thermal effects. In short, tiny tiny bits of the chip probably getting hotter than they are speced for, and are (possibly) slowly taking damage. How long it will last is anyone's guess. It's possible the output and input stage are overbuilt. It's possible they tried to make it 5v tolerant, but the design wasn't robust enough for marketing it as such, but it's still very built up. It's possible your particular chip had some manufacturing variability that improves its resistance. The circuit you have hooked up to it might be current limited enough to never cause a problem. Or it may die tomorrow as the overstressed transistors finally burn out. You're using it way out of the datasheet specs, and there is just no guarantee about its behavior.
|
|
#
¿
Mar 10, 2013 21:39
|
|
|
HATE TROLL TIM posted:I see. That makes more sense. I didn't think about a slow death. Though, if I've got a resistor between the data pins, that should current limit it, right? Couldn't I also connect the appropriate sized resistor between the data pin and ground to reduce the voltage? (A resistor divider circuit I guess.) While current limiting could potentially prevent damage, you'd never really know what the proper level is, because there really isn't a proper level of current when you're feeding more voltage that it's speced for. There are quite a number of issues that can introduce gotchas in using a series resistor. There are also some concerns about the direct effects of voltage as well. There are circumstances where it is the perfect solution, but really it just isn't recommended. Voltage dividers are a very common way of doing this conversion. They can cause problems with very high speed signals, but that's not something you need to worry about. The sparkfun board Rexxed linked to incorporates a voltage divider. As an aside, stepping up from 3.3 to 5v logic rarely has problems. Most 5V logic accepts 3.3v as logic high, so you can just plug a 3.3 logic out into a 5v logic in. It does reduce the margin of operation, and thus reliability, but it does generally work.
|
|
#
¿
Mar 10, 2013 23:43
|
|
|
evol262 posted:This utterly misses the point, and the technical limitations of FPGAs regarding pin output limitations are trivially solved. Considering you know the requirements chip you have to drive, the pin output limitations of a microcontroller are borderline trivial. Sure, on a FPGA you can just hook it up to pin x, and on a uC you have to hook it up to pin 8, oh well, the board will be routed slightly differently. Once it's built, it's not like the driver chip is going to change where it's i/o is. And if you move to a different driver, you'd probably have to reroute anyway. The real reason for the rise of the MESA cards is that the parallel ports, even in industrial computing, are going away and people want an ever increasing amount of i/o data directly into the computer. And for this, yes the parallel capabilities of a FPGA is a great tool. But then you're talking to a PCIe or PCI bus. With the LOGi, the best you're going to see is SPI bus speeds. The non internal bus mesa cards are really just there to support the line and make it look complete. Using the USB one for example will always be hobbled by the fact that USB has huge latency. It'd still be fine for low speed or non synchronous applications. Its the same reason why just about all USB cnc controllers have an onboard interpreter. Different paradigm. But really, I think bringing up the MESA cards actually explains a lot about your perspective. You're more talking about building more or less arbitrary systems about of much higher level components. If you've already used 30 of your available 35 channels connecting to random stuff, and all you have is a random assortment of pins, and you need a clock, you absolutely need to be able to call one of the last available pins as a clock for the next thing. Or have I mischaracterized your problem? Going back to the LOGi for a moment. I can see it being a useful GPIO expander and preprocessor, but at the same time, the RPi is a slow machine with a slow bus and doesn't really need the help of a high speed data adapter to swamp it. The beaglebone has more computing power, and is closer to the fast computer + bus + i/o on the bus model. Except it still has a slow bus. It also has plenty of native i/o. Still, to take an ocilloscope as an example, plenty of them are a fpga + an ARM, and you end up with more than the sum of the parts. For motion in particular the RPi could probably use it to get enough i/o to drive a bunch of channels, but I can't help but think that a board with collection of bog standard i2c gpio expanders and motor drivers wouldn't be the more economical solution. It is unfair to compare a general purpose device to an optimized solution though.
|
|
#
¿
Dec 17, 2013 20:15
|
|
|
Hadlock posted:So apparently you can build a joystick using two hall effect sensors, three if you want a throttle, a magnet, and an arduino and the unojoy library, but only has 6 input pins. Did you see the leonardo port, LeoJoy?
|
|
#
¿
Dec 21, 2013 07:05
|
|
|
Computer viking posted:What's the "correct" way send a high-signal to the arduino with minimal components, anyway? A transistor and 5V from somewhere? If you want to make it out of discrete components, a transistor, a pull up resistor, and a current limiting base resistor (if you're using a bipolar) is typical. The typical configuration will give you inverted logic, so you'd either deal with that, or add a second assembly to reinvert it. A level shifter IC, such as the TXB0102, would probably be better still. It'd be more flexible and less prone for error.
|
|
#
¿
Jul 29, 2014 15:28
|
|
|
|
| # ¿ May 20, 2024 17:50 |
|
|
hayden. posted:I got a Raspberry Pi recently and I'm pretty new to all this. I have a DS2431 EEPROM I'm trying to read that uses OneWire. It shows as a folder under /sys/bus/w1/devices/ called "2d-00000c6b09f5" but it doesn't appear to have a "w1_slave" to read to show data like tutorials show for many other components (like temp sensors). Any idea how to read this? Is this helpful? http://owfs.org/uploads/DS2431.html. There's an "rw" file that outputs a bunch of blocks (like a missing character?) - is there some way I should be reading this? I'm trying to figure out the owfs right now if that's the solution but it looks like maybe it doesn't work with w1-gpio (looks like it traditionally uses a USB adaptor of some sort). I suggested you come over here because I do not know the rpi, someone here might be able to give you better advice. But I do know one wire. Be certain that whatever you call pin 1 in code is actually pin1 on the header. My five seconds of googleing indicates that pin 1 of the controller isn't even connected to the header. For example, it appears that pin 6 on the header is connected to pin 17 of the rpi's processor. Pin 1 of the header isn't GPIO at all either. It's just fixed power. For a onewire device that uses the same pin for power and data, plugging into this won't do anything at all.
|
|
#
¿
Sep 21, 2015 01:26
|
|