Update DMX Basics guide - Artemis SBS Forums

Author

Comment Page 2 of 2 Prev 1 2

Dave Thaler

Registered:1424550389
Posts: 445

Posted 1552977053	Reply with quote #16

Quote: Originally Posted by e4mafia Interesting experiment today. I set up an ART-Net profile in DMXTools on a non server station, and set Wireshark to monitor the IP output. I connected that system to a server on a different PC, and sure enough, that station, which I set as helm, is in fact putting out DMX. Did anyone else know this? Does EVERY system output DMX? This opens up some cool possibilities for a lot of things on individual stations, if you don't need some kind of master relay to communicate out to the various areas. That's a feature of Artemis Bridge Tools, Artemis does not do it natively. And yes, every station gets DMX cues relevant to that station.

e4mafia

Registered:1534343715
Posts: 160

Posted 1556568683	Reply with quote #17

Does every station get all cues, or only "relevant cues"?

e4mafia

Registered:1534343715
Posts: 160

Posted 1556568932	Reply with quote #18

Quote: Originally Posted by Angel of Rust For my setup, I still want the controllers talking to each other (power level updates from engineering, for example). However, the prospect is interesting. I can see how this could be useful for communicating the kinds of things that the DMX interface may not be tracking, from one station to another. Oh the possibilities.... I really love what you've done so far. Theres something to me somewhat appealing in going the individual route too. Decisions decisions. Question, can that USB interface you use on the dmx receiver side also act as an HID? Or would we be looking at a receiver FTDI and processing feeding as input to an arduino/microprocessor, which then USB's into the station as an HID for keyboard/mouse inputs? Can a single device (i.e. 1 Arduino) handle both directions, without needing a second port?

Angel of Rust

Registered:1483481942
Posts: 234

Posted 1556589315	Reply with quote #19

Quote: Originally Posted by e4mafia I can see how this could be useful for communicating the kinds of things that the DMX interface may not be tracking, from one station to another. Oh the possibilities.... I really love what you've done so far. Theres something to me somewhat appealing in going the individual route too. Decisions decisions. Question, can that USB interface you use on the dmx receiver side also act as an HID? Or would we be looking at a receiver FTDI and processing feeding as input to an arduino/microprocessor, which then USB's into the station as an HID for keyboard/mouse inputs? Can a single device (i.e. 1 Arduino) handle both directions, without needing a second port? I can't speak for many of the other Arduino controllers out there. However, the Teensy-LC that I am using for my designs has four built-in serial ports - 1 dedicated to USB communications and the other 3 configurable for UART. When I developed the original concept for the "Block III" controllers, I had the idea to communicate information between control consoles directly and allowing for the flexibility to upgrade control panels and DMX effects in the future. The current "ACP3" iteration is just a refinement of that concept. In this design, each controller is, at a minimum, capable of functioning as an HID, taking input from at least 3 modular control panels AND communicating with the Artemis client via USB, AND communicating with the other controllers. The fully-loaded DMX variant can do all of that AND read the DMX output from the Artemis host. Here is a sketch of the system topology: Here is one of the fully-loaded controllers plugged in to Artemis host (viewscreen - white USB-B), Artemis client (black USB micro-B), and the other control consoles (red cat5 cables): Here's the schematic for the controller: You'll notice that, if I want to hook-up a standalone DMX control circuit, I can take the signal from J8 and wire it into another SP348, just like for the USB-DMX interface (that would allow me to have one control panel and the all the DMX cues running through one box): Here's a closer view of the control board showing where J8 is (upper right, just above the Teensy-LC): Also pictured is the bank of control panel headers (bottom left), the RS485 circuitry to connect control consoles (top center), the FTDI interface with Artemis (middle), and the Teensy-LC that runs the control console program and emulates the mouse/keyboard/joystick combo to the PC. I am including all of these capabilities on one board to afford maximum flexibility to me and whoever else wants to use this design for their control panels. Finally, not all of the controllers need to take the DMX input directly, so the basic board configuration just leaves off the FTDI part to save cost: Fun food for thought - since these controllers are fully-programmable, bridge builders can work in any capabilities they want incorporating communications between consoles. For example, an early concept I had for "Block III" was to allow individual stations to toggle power settings, science to switch beam frequencies, and science to pre-program course headings (see photos below). Ultimately, I decided to go a different direction, but it would be easy to do.

e4mafia

Registered:1534343715
Posts: 160

Posted 1556593751	Reply with quote #20

That sp3485c - is that basically a low power (3.3v vs 5.0v) version of an SN75176? Differential Bus Transciever? Question for controls - if you've got a bunch of switches and lights to hang off one of these boards, do you have a design for a shift register that would connect to the headers on this board? I thought I saw one before. Have you thought about building one into this board, or is modularity the key driver in this? I think thats what you're going for, right?

Angel of Rust

Registered:1483481942
Posts: 234

Posted 1556674301	Reply with quote #21

Quote: Originally Posted by e4mafia That sp3485c - is that basically a low power (3.3v vs 5.0v) version of an SN75176? Differential Bus Transciever? Looking at the specs for both -- probably yes. Block III used these and they worked perfectly, so I just stuck with them. Quote: Originally Posted by e4mafia Question for controls - if you've got a bunch of switches and lights to hang off one of these boards, do you have a design for a shift register that would connect to the headers on this board? I thought I saw one before. Have you thought about building one into this board, or is modularity the key driver in this? I think thats what you're going for, right? Yes to all questions. Modular design is very important to me. I ran the numbers and it is considerably cheaper to chain a bunch of shift registers on separate PCBs than it is to increase the size of cable and/or PCBs and/or number of cable connectors. The upcoming Helm center panel has three separate shift register boards on the same cable -- much cheaper! Plus, since it is modular, it is very easy to swap out parts and/or re-use the same controller. Here is the design for the shift registers. I copy and paste this schematic into all of the control panel boards: 20-pin (center panel) variant: 10-pin (side panel) variant: I have a bunch of shift register boards left over from the Block III project. They work fine with the new controllers - just need to swap one of the wires around when connecting: They have an 8 x 8 LED matrix (8 source, 8 sink) and an 8 x 2 (or 3) button matrix. It's more than enough for most control panels. I have considered making an updated version (shuffle the pins around and switch to SMD ICs) for ACP3 projects, but since the old boards work just as well, there hasn't been a pressing need.

e4mafia

Registered:1534343715
Posts: 160

Posted 1556715971	Reply with quote #22

I just love talking to you about this project. It keeps me occupied when I don't feel like doing work at work 😉 I could ask questions all day. So on the controller, J3 and J4, those are your RJ45 connectors. I see the +/- data as A&B. and I See POE, I'm assuming that's pushing 5v across those? So on the other end of a link, lets say a "remote" control station, (that is only connecting to a bridge station, and is not using a second USB connection to a view screen to receive DMX) - does that end use this 5v as its primary power source for its teensy & other components, and lights? or is it using that in combination with the 5v draw from its own USB connection? Or is it something I'm missing entirely? I know I was curious before about the code you used to read in the DMX from the FTDI into the teensy - I was never able to get that to work on my Arduino/redboard/mega - just too much low level stuff to sift through and was just so much easier for me to pull it from ARTnet. Now O'm very curious about how your setup works post-serial input. How you manage the shift registers, distribute to the remote boards, and how those remote boards take that in and do the same. I have to imagine there's a fair amount of modularity in the code base as well. But each station does need to be customized, code-wise in some way right? Is your code up on GitHub or someplace like that I can take a look at? Understandable of course if you don't want it completely loose in the wild though. Thanks again, over and over for sharing your project with us. I've learned so much from it already, and my own bridge is starting to move into controls now. Just ordered the first batch of parts for making a weapons console. Gonna build these one at a time and just see how it goes. -Bob

Angel of Rust

Registered:1483481942
Posts: 234

Posted 1556765495	Reply with quote #23

Quote: Originally Posted by e4mafia I just love talking to you about this project. It keeps me occupied when I don't feel like doing work at work 😉 I could ask questions all day. So on the controller, J3 and J4, those are your RJ45 connectors. I see the +/- data as A&B. and I See POE, I'm assuming that's pushing 5v across those? So on the other end of a link, lets say a "remote" control station, (that is only connecting to a bridge station, and is not using a second USB connection to a view screen to receive DMX) - does that end use this 5v as its primary power source for its teensy & other components, and lights? or is it using that in combination with the 5v draw from its own USB connection? Or is it something I'm missing entirely? I know I was curious before about the code you used to read in the DMX from the FTDI into the teensy - I was never able to get that to work on my Arduino/redboard/mega - just too much low level stuff to sift through and was just so much easier for me to pull it from ARTnet. Now O'm very curious about how your setup works post-serial input. How you manage the shift registers, distribute to the remote boards, and how those remote boards take that in and do the same. I have to imagine there's a fair amount of modularity in the code base as well. But each station does need to be customized, code-wise in some way right? Is your code up on GitHub or someplace like that I can take a look at? Understandable of course if you don't want it completely loose in the wild though. Thanks again, over and over for sharing your project with us. I've learned so much from it already, and my own bridge is starting to move into controls now. Just ordered the first batch of parts for making a weapons console. Gonna build these one at a time and just see how it goes. -Bob I feel like the custom controls discussion has hijacked the original intent of this thread. I will continue the conversation over here: https://artemis.forumchitchat.com/post/acp3-modular-controls-10122845?pid=1308447235

e4mafia

Registered:1534343715
Posts: 160

Posted 1556766695	Reply with quote #24

yeah, definitely threadjacked there, sorry!

Previous Topic | Next Topic

Page 2 of 2 Prev 1 2

Modal title

Insert Code

Please paste your code into the box below: