bilderbuchi

Build log is finished and online: A big thanks to everyone involved! This project wouldn't have been possible without the help of this great community! :hug:

MIDIBox SlideControl is a remote control solution for Kodak Carousel slide projectors aimed at event usage. It was a sometimes painful process of about 1.5 years to arrive at the solution at last. Success would not have been possible without the great midibox community! Thank you! Introduction One box "on stage" receives MIDI and button presses to switch slides forward/backwards. Due to the long distances to be bridged (10-50 meters), it was necessary to use the CAN protocol/MBNet to transmit the necessary information to a distribution box (typically up in the rafters/trussing), from where up to 8 slide projectors are controlled in a star topology. Control is achieved by closing an electric circuit of the projector via a reed relay for total electric insulation. Preliminary test confirmed that it is possible to transmit control information over 100 meters (!) of ordinary cable. The CAN protocol maximum specified distances lie in the range of 7 kilometers, only dependent on bit rate. Due to the nature of the CAN protocol, it is easily possible to add further distribution boxes and daisy-chain them from the first one. One could control more projectors than I care for that way (>=64), only limited by MBNet address space. One nice consequence of the design is, that XLR-cables, which are ubiquitous in event production, can be used for the cabling of the whole project (stagebox->distrobox, distrobox->projectors). Stage box The stage box consists of one PIC8 core stuffed with a 18F4685 (necessary for the included CAN interface), one DIN for the buttons, one standard character LCD, and a small self-designed PCB for the CAN driver/transceiver, all put in some plastic case I had lying around. Distributor box The distributor box consists of one PIC8 core (with 18F4685 as before), and a self-designed PCB containing half a DOUT, the CAN driver circuitry, and the reed relais. XLR plugs etc. made the whole affair a little cramped (the core is actually stacked on top of the self-made PCB!), but I am very satisfied with how it turned out. Some adapter cables and a connection tester made the whole thing complete and ready for action! Software The software is basically a MIDIO128, augmented with the MBNet parts I ripped out of Midibox SIDV2. Due to MBNet only being available in assembly, I had to stay with a programming language I don't actually speak. TK was an invaluable help in merging the relevant source codes together! The software forwards button presses to a distrobox. Since the distroboxes have Device ID's starting from one, it was possible to route received MIDI events to distroboxes depending on the MIDI channel, so events on Channel 11 only go to distrobox 1, Channel 12 to number 2, etc. I chose to start with Channel 11 to avoid interference with common MIDI control messages, which are typically on CH1. I would rather not just put the code online here, because it is actually quite a hacky solution, and most probably affected with bugs I haven't found, and definitely not programmed elegantly. I only grafted MBSid code onto MIDIO128 in the crudest way possible, and I don't really know how to program assembler, it was much more "educated copy-paste". I will definitely send the code on request, and I did everything in a git repository, so it should actually be possible to follow my changes, and adapt them to you own needs.

I reduced the default CAN data rate (I guess it's the CAN max of 1MBit/s but never calculated it) to 1/8th of its value; in mbnet.inc: This (128kbit/s?) should still compare favorably to MIDI (31.25kbit/s if I'm not deceived). :) The reason: As per the CAN specification, 1MBit/s is only specced for cable lengths <=40m. this length progressively rises to some 7km(!) for the lowest data rate of 10kbit/s. I just chose something convenient in between. A table I found somewhere: Bitrate cable length 10 kbits/s 6,7 km 20 kbits/s 3,3 km 50 kbits/s 1,3 km 125 kbits/s 530 m 250 kbits/s 270 m 500 kbits/s 130 m 1 Mbits/s 40 m

It works! :frantics: Assembled and nearly finished at last, adapter cables are about the only thing left. Will try to write some documentation soon(ish). btw: CAN with low data rate over 100m generic cable with no problems.. :D

sounds like a nice project, i've been meaning to look into such an ultrasimple step sequencer for some playful visuals triggering... :sorcerer: based on 8bit or 32bit core?

welcome james. :) TK, how to go about the missing midi out on the meeblip with respect to checksums and retries?

couldn't you bend the lcd legs so that they go vertical and through the pcb two or three holes to the right in your pic? then you would have a rather long horizontal lever which i think would be flexible enough to accomodate 1.5mm travel?

you guys raise some interesting points. i figure you could always ask them and/or contribute your findings in the comments, i'd think that the guys over at CDM are quite open for feedback, and judging from their posts over the last year(s), alternatives are always welcome. one thing i don't get is the decision to require a chip flasher to reprogram the device - the midibox way is soo easy/comfortable. I think this will stymie software development quite a bit.

just wanted to throw this here, maybe it's interesting for one or the other.. Meeblip, The Open Source, Hackable Digital Hardware Synth http://createdigitalmusic.com/2010/11/meet-meeblip-the-open-source-hackable-digital-hardware-synth/

just a quick report: code worked out, i'll let the software side rest for a while. Many thanks for your help! Now on towards CAN transceivers! Initial experiments were unsuccessful, but maybe I'm too tired. Still lots of options left: reducing the slew rate, terminated bus ends, taking the oscope to the circuit...

TK, i love you :cool: thanks for the code, just what i needed! will test this in the evening! yes, this comes from CS_MENU_MBNET_Tx_SendEvent (the original function SimpleSend is based on). It's also contained in CS_MENU_MBNET_FoundNode, which is called in the MBNET_ConHandler, so I thought it may be important elsewhere. will do. reason i didn't is because in midi_evnt.inc, where I call the CAN sender, this is not the case: ;; -------------------------------------------------------------------------- ;; FUNCTION: MIDI_EVNT_Send ;; DESCRIPTION: sends a simple MIDI event ;; IN: ;; o first MIDI event byte in MIDI_EVNT0 ;; o second MIDI event byte (if applicable) in MIDI_EVNT1 ;; o value in MIDI_EVNT_VALUE ;; -------------------------------------------------------------------------- MIDI_EVNT_Send ;; -------------------------------------------------------------------------- ;; MBNet stuff (BB) ;; hope this is functional code: call CS_MENU_MBNET_Tx_SimpleSend I didn't want to overwrite the MIOS_PARAMETERs because of the dependencies you pointed out in the new code - i didn't want to break something inadvertantly by overwriting values.

A major success: I tried to do it "properly", i.e. by using the above line; no luck, no CAN activity, except for the first buttonpress after booting. Then I hunted around (maybe CS_MENU_SID is not defined in midi_evnt.inc, where the function is getting called? Don't know if something like scope is even possible in asm...) Anyways, I found some code where SID numbers get assigned (CS_MENU_MS_GetSIDNumber). from there I took some snippets and hard-coded the value of CS_MENU_SID. I know, not exactly nice style, but at least it works now, consistent LED triggerings! :frantics: I ended up with CS_MENU_MBNET_Tx_SimpleSend movlw 0x01 movwf CS_MENU_SID movff CS_MENU_SID, MBNET_SLAVE_ID ; prepare transmission I don't understand why I can't leave the first two movs out, and only write movff 0x01, MBNET_SLAVE_ID, but I'll leave it at that. This actually generates some more problems: Re-discovering nodes, a second distributor; any kind of CAN status messages still don't work; but I have accomplished enough for today. Now I know 100% that the setup I envisioned so long ago will really work, and can finish building the box. After that I can (maybe) work on more software polishing. One last thing that optimally goes into the software before all that: Can aynbody tell me how/where I can arrange that, depending on the device Id (i.e. only on the master core), all midi in messages get forwarded to midi out? then this box will also be controllable by external midi, and I don't have to duplicate the CAN-transmit-code somewhere else. I can't simply put the CAN transmit code in USER_MPROC_NotifyReceivedEvent, because that's where CAN/MBNet puts the Midi events it transports, and I think this would generate an endless loop... :no:

ah, great. :-) ic. diodes are ok. i ruled out hardware errors due to the fact that the intermittent firing of CAN events already starts at the master core Tx pin, so i thought there's got to be a software error. good idea. i'll try midi messages. i already (unsuccessfully) tried to adapt the function which yells if there's a midi timeout to notify on the LCD if there's a CAN node found. thanks for the heads up. unfortunately, i don't think i'm expert enough. it didn't work with this line (no pins triggered at all). which is why i figured i use this instead movff MBNET_RETRY_NODE, MBNET_SLAVE_ID since, with only one slave node, the retry_node id should be the right one. i will look into that again, maybe the retry id changes often, which is what produces the intermittent behaviour. of that i'm, unfortunately, quite sure. :-( coding assembly is like "topfschlagen" for me, where it can't take a pro very long to make the necessary modifications. i already reduced the planned feature set considerably. i'll be glad if i get it working at all. :-(

Oh, hello can of worms. If I include cs_menu_mbnet.inc, I get loads of "Symbols previously not defined" errors. Many could be fixed by extending app_defines.h. Unfortunately, there are overlaps in the addresses (?) between MIDIO128's and SidV2's app_defines.h, e.g. MB_STAT EQU 0x010 and SID_STAT EQU 0x010, respectively. And that's not the only one. That can't be good, right? Also, if I include some (or the whole) of the cs_*.inc files, there's even more errors on make. I'm not sure anymore if this approach makes sense? I think the whole app is just too tightly integrated... :cry:

thanks! thanks for the forum/access, too. Write access won't be necessary, though, I wouldn't want my code be included in the "official" repo. It's way too primitive and possibly full of errors and bugs (I don't actually speak assembly, what I do is educated-copy-paste!). Regarding cs_menu_mbnet.inc and sid_mbnet.inc: I didn't want to include them because I didn't want to make the code even more complicated with stuff I don't need (no SIDs anywhere near), and wanted to avoid the Control Surface fighting with Midio128 for control of the LCD. I will try to include them, though, and see if it relieves my problems. @ Frames on the RX pin: Isn't this ensured by the wired-and connection already? I wired the CAN bus according to the pdf (as already mentioned above). CAN transceivers are already on my desk, eagerly awaiting a working solution with wired-and. I wanted to avoid introducing too many unknowns at a time. To clarify: I'm puzzled why the CAN-functionality works only sometimes. I'd have expected all or nothing. Is it possible that something gets reset in between? Although I haven't observed a necessary waiting period or whatnot, sometimes the recognized buttonpresses are quite close together, sometimes very far apart...well, I'll try including the rest of the code and see what happens... btw TK, do you have any input regarding the MIOS-Studio-on-Linux thread? It would be a bit more comfortable, I think, not having to work in the old beta9. But it's not that important...