DOut over long (50-100m) cable?

[bilderbuchi]

Hi folks!

I've been lurking on these forums a couple months now, but now I've run into problems I can't solve by just reading (which i did alot lately)...

Intro:

I am currently building a Midibox as a midified remote control for a couple of old slide projectors (for event/visuals use). button press or sending midi notes should actuate fwd/rew on the slide projectors via reed relais. The Midibox resides in a stagebox with a couple buttons, and a distributor box (with a Dout and an array of reed relais) should be up in the rigging near the projectors. Sending the Dout signals over the long connection shall enable us to only use a 5-lead cable instead of the 24 leads (or more if scaled up) needed for 8 projectors. i have estimated that a cable length of up to ~50m is necessary for our purposes.

The box is built already, i got the software operational so far, but now i've run into a problem i didn't expect:

Problem:

Everything works as intended if i only have a short (30cm) connection, but now i have connected the core and dout with a 100m long 5x0.14 braid shielded cable (still coiled up if that matters; resistance of one lead is about 10ohms; i didn't cut it just for trying out because it's (still) a friend's cable), and now nothing works anymore. i can't actuate the reed relais and leds i connected anymore (sometimes only flickering), and even the Din readings of my box seem to be affected if i interpret the LCD readings right.

Troubleshooting:

I figure that the long cable length somehow interferes with the Dout signals. i found an old thread talking about cable impedances etc http://www.midibox.org/forum/index.php?PHPSESSID=c43cebc93f105690a49ba30c21b1f6a9&topic=6570.0 , i am currently reading the linked pdf. i could kick myself that i didn't think about this earlier. :(

I reconnected pins, so that power is fed to the Dout over a short cable directly from the core's J2, figured that maybe the long run let the voltage drop too much, didn't help.

I connected the cable's braid shield to the power grid's earth, changed the behaviour slightly (more flickering, chattering relais) but still erratic. It should be earth for shielding, right? not the Core's ground?

I have no easy access to an o-scope so i can't check the signals before and after the long cable.

Question:

Is it even possible to let a Dout signal set run over such a long distance?

Would it be possible to reduce the update/multiplexing/SR frequency or whatnot of the Dout signals? I don't need ms-accurate timings, ~half a second would be way enough, so maybe this could be relaxed?

Do i maybe need special circuitry for boosting the signal before and after the cable? or would terminating the cable correctly resolve this problem?

Is it feasible to use other circuitry to enable another/slower switching method for driving 16 up to 32 reed relais? meaning, stuff the Dout into the stagebox, use the dout to drive some other elements, which are more robust with regard to long lines, while also minimizing the number of leads needed for the "long haul"?

Well, thanks so far for any answers!

edit: tried sending the Dout (-power) over 10m XLR cable, works much better, although some strange things happening (1 button actuates two leds, one flickering), so i think signal degradation is already setting in here.

the reason i also want to transmit power of the long cable is that, while i could build a PSU into the distributor box, i fear that different ground levels (with switching psu's, or if the distributor is connected to another phase of the power grid) would also cripple operation. using 3-pin XLR cable would be best because of its ubiquity, but the ground level question remains. isolation with optocouplers is not feasible because there is no return path available in an XLR cable (3 leads, no shield).

[lylehaze]

If I were in your position, I'd try two things:

Assuming the slide projectors are fairly close to each other, move the MIDIBox and it's DOUT modules up into the rigging, as close to the projectors as possible. Use a long MIDI cable, but keep the MBox to DOUT ribbon as short as possible.

If that fails, Next step would be to use CAN to link two midiboxes, one upstairs and one where you need the controls. As long as you use "real" CAN transceiver chips, the distance and speed specs are clearly spelled out.

The signals between the core and DOUT module are TTL, and are not designed to be separated by much distance.

If the slide projectors are not close together, you may need a core at each projector to handle your needs, or longer wires from the DOUT module to the separate projectors.

Let us know how it works out!

LyleHaze

[stryd_one]

Welcome aboard mate.

Yeh 100m is way past what a DOUT will handle, anything >1m unshielded and maybe a bit more with shielding, is unlikely to behave. Honestly 100m is a long way (that's 300ft for you 'merkans) and if it were me, I'd be looking at a PC+midi interface at either end sending midi over ethernet. Otherwise, you're up for some serious DIY fun as per Lyle's post.

[bilderbuchi]

lylehaze: projectors are not close together (~10-20m, depends on the setup), but this does not matter because the distributor box only closes an electrical connection (via reed relais) in the projectors.

moving the midibox up into the distributor would be a possibility, but i would lose the display and control via (hardware) buttons onstage. yes, i could add another midi controller or control solely with software, but both options i don't like. also, afaik midi connections are limited to 15m cable length?

CAN is a neat idea! a quick search showed these interfaces are quite expensive, though (1-200€?). or can i use the CAN capabilities of the upcoming STM32 core (as the spec sheet seems to indicate)? CAN would be beautiful because it would be possible to use XLR cables! :) also, maybe SPI would be better? or is CAN the optimal bus for my application?

edit: seems the cost is not so high after all? the IC's themselves are quite cheap. i have to see how easily they would be integrated into my system. well, more reading necesssary....

thanks for clearing that up about TTL. now i know i can drop the initial concept.

stryd: thanks for the confirmation. a PC at the distributor end is unfeasible i fear (too big, clunky and sensitive), i need a sturdy little box.

if CAN of the new core is not possible maybe i find an alternative protocol is usable (XLR/DMX or OSC).

well, thanks guys for the input, i'll read up about CAN and the new core. is there an estimate when will it be available to us mere mortals?

i will definitely keep you posted, and i hope i will have footage of some nice projector-synching goodness at the end :)

[cimo]

What about this:

fisrt you amplify a bit the signal out of DINs and DOUTs, a bc547 will do then in the projector room you build a matrix: 8 projectors x 2 switch each = 16 pins, that could be accomplisehd with a 4DINx4DOUT matrix, that makes 8 cables plus GND or V+. You need 9 cables that is a shielded 8 cores cable, cat6 LAN cable for example? Can t remember right now, or 2x 4cores cable.

Simone (would this work?)

[stryd_one]

The new core will be ready when it's ready. Don't get too swept up in the rumour mill eh? ;)

And it'll be the same deal as before electronically (Wired-AND), so you won't gain any advantage there anyway. SPI would be worse. A PC does not need to be big or clunky or sensitive, think about an Asus EEE-PC just to name one premade example, it's not much bigger than a core+DOUT anyway... Anyhow I would not want to discourage some experimentation with CAN transceivers, so go for it!

[bilderbuchi]

yeah i kinda expected that answer.;-) was just hoping to plan accordingly. if it comes out in two months i'll wait and go stm, and build a midirouter/simple step seq beforehand), if it takes another year that's too late for me, that's why i asked.

anyway, point is that, as i understand it, the STM core has a CAN transceiver (and presumably the routines to access it easily) built-in, that's the advantage i gain.

with the old one i'd have to learn how to rig a transceiver together myself, and program the routines to be able to use it (in C since i don't speak asm). i'd have liked to spare myself...

well, rumor mill, it's posted on the ucapps mainpage, after all...if that's no tease, i don't know what is ;-)

cimo: sounds reasonable, i'll look into it! at least 9 cables is less than the 24 (or 16-18 depending on wiring) which are necessary if i physically pull the switches into the stage box - this is the case with the current control box for 8 projs of a different make (short press: fwd, long press: rew), uses an LPT cable... fat and stiff, a real joy to rig. :P

[lylehaze]

CAN is ideal for this.. as the physical layer, anyway.

the PIC18F458 is basically a 452 with CAN added. I use them here for many projects.

Wasn't there a MB_NET project on the PIC core? That would be most of the battle right there.

One thing to look out for: When using CAN between cores that are close together, we sometimes just link the chips without "proper" CAN transceivers.. if you want distance, I'd be sure to use the proper chips to drive the wire.

If you want to stay all MIDIBox, consider splitting the job between controls on the "downstairs" box and outputs on the "upstairs" box(es), with CAN between them. The cost of the extra core is pretty reasonable.

CAN trivia: Was originally developed by Bosch for automotive networking. CAN is also the physical layer of DeviceNet, frequently used in factory automation.

The "built-in" error detection and management is very attractive to hackers like us. The biggest limitation of CAN is 8 byte messages, but that is no problem for a MIDI environment, where most messages are 3 bytes or less.

I've been up all night coding a new MIDI toy.. I'm a bit punchy..

Have Fun,

LyleHaze

[bilderbuchi]

thx. yes two cores linked by CAN seems to be the most prudent and elegant way.  :)

a quick check of the specsheets yesterday night revealed that the pins for CAN on the 458 are occupied by the LCD connection in the core pcb. if i understand that right, i couldn't use a 458 on a normal core module? or is it possible to internally reassign CAN to another pin in the 458?

i'll be looking into that MB_NET stuff.

[stryd_one]

Just use a 4685 and MBNET. All you need to tink about is the transciever ICs.

As for planning around unreleased hardware: as soon as we know a fixed date, so will everyone else.

[lylehaze]

4585 is the correct chip.. my old 458's are outdated.

Since the CAN connections are on the LOW half of port B, you can still run the LCD in 4 bit mode, which will free up RB0, RB1, RB2/CANTX, and RB3/CANRX.

You'll need CAN transceiver chips. They come in 3.3 and 5 volt types, most are SMT, but Digi-Key currently shows 3 that are 5 volt and in a DIP package. All priced less than $2.50 USD in single quantities.

I didn't know the status of the MB-NET project, but it is definitely the best place to start.

Sounds like a fun project!

LyleHaze

[stryd_one]

MBNET is what MBSID cores use to talk... it's very active :)

[bilderbuchi]

thanks for the infos guys! i think my path is clearly outlined now  :P

[bilderbuchi]

well, it's been a while, but things have happened. i got 2 cores now, with 18f4685 chips, and 2 CAN transceiver IC's, so I'm more or less set. :-)

Question 1: I adapted the MidIO128 application for 4bit LCD mode by inserting the relevant code (from the wiki) into the main.inc file. I got a second LCD where I cut D0-D3 as per the CAN instructions for the 18F4685. Interestingly, 4bit mode or not does not make a difference for the display.

I tried the unmodified display, and the one with the cut wires with both an unmodded MIDIO128 application and the one using the 4bit mode, in all permutation the display just works, I can't spot any difference. Is that correct behaviour? I'd have thought that an LCD with these 4 wires cut wouldn't work anymore in "normal" mode.

I haven't wired up the CAN transceivers, so can't say anything about that side of the story. One step at a time...

Question 2: I plan to use MIDIO128 as the base for my program (it's simple and does all I need button/midi/controlwise, just have to control one DIn, one DOut). I already included the 4bit mode to free the CAN interface pins as per question 1. Now I have to include the MBNet functionality into MIDIO128. How do I do that? Is there a library or source file to more or less drop into the MIDIO128 source code? (Like a C .h/.c file, #include and you're all set)

Also, I have to persuade the app in the stagebox core to forward all midi signals via MBNet/CAN to the core in the distributor box. How/where do I do that? I have to admit I'm overwhelmed by the MBNet wiki page.

Question 3: Is there a C-based application that would be more usable for my purposes? I don't speak assembler, so any modifications will have to be more or less copy-paste, but speak C well enough to modify existing code if it's not too hardware-near. I think... :-)

thanks!

Edited October 26, 2010 by bilderbuchi

[TK.]

Hi,

the MIOS8 variant for PIC18F4685 always selects 4bit LCD mode, regardless of the SW configuration - this was the easiest way to avoid that users have to consider this, resp. that special application firmwares have to be released for this derivative.

MBNET for PIC: only exists (and only makes sense) in assembly language:

http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fsrc%2Fmbnet.inc

For MBHP_CORE_STM32 a C based variant (customized to the CAN interface of STM32) exists:

http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fmbnet%2F

It isn't possible to adapt this library to a 8bit controller

Best Regards, Thorsten.

[bilderbuchi]

regarding 4bit mode: great, thanks for the info!

thanks for the link to mbnet. i'll dig in and see if i can make sense of it. :-)

[bilderbuchi]

so, an update, and questions:

The setup:

I now have one core, the stagebox (with a DIN), and one core, the distributor (with a DOut with LEDs on the pins), and linked them with a CAN/wired-and interface on a protoboard (as per the mbsid v2 communication pdf).

I have adapted midio128 (2.2c) with code from midibox_sid_v2_0_rc37. Included mbnet.inc, and hopefully added all the necessary stuff (in main.inc, app_defines.h. at least i have no errors when make'ing. Initialized the CAN interface, and in USER_Tick, call MBNET_Handler.

I took the function CS_MENU_MBNET_Tx_SendEvent (sends midi event over CAN, exactly what i want), adapted it a bit, and included it in midi_evnt.inc in the function MIDI_EVNT_Send, so that when a midi event is sent, it's also transmitted via CAN.

The distributor reacts to incoming midi signals, and switches dout LEDs (as per midio128 standard functionality).

The problem:

I have sucessfully triggered LEDs via CAN with this setup. The problem is, this does not happen consistently, I only get a triggered LED in about 20-30% of button presses. I don't know why, MIDI gets transmitted correctly every time.

Diagnosis: I took a simple oscope to check the CAN bus. when an LED is triggered, there is activity on the CAN bus. Suspecting an error in my hardware setup, I connected the CAN pins directly to the jumpers on the core pcb (not via the flat cable), no change. Apparently the problem lies with the sender in the stagebox core, since there's only activity on the Tx pin when an LED is triggered, too (so not on every button press as it should be). so the bus transmission seems to work well, so i suggest a software problem. Correct?

I don't know what to look at, assembly coding feels like building a model airplane with a chainsaw and a caulking gun.... I'd be glad if someone could help me, since the functionality I need does not seem too complicated (basically send Midi also via CAN on every button press).

Many thanks for any efforts!

I have to applaud the very well-commented code! Without those comments any efforts on my part would have been doomed from the start.

Btw I wasn't sure if I should split this off into another thread in the programming section, or not.

Code snippets:

MIDI_EVNT_Send

;; --------------------------------------------------------------------------

;; MBNet stuff (BB)

;; hope this is functional code:

	call CS_MENU_MBNET_Tx_SimpleSend

;; --------------------------------------------------------------------------

 	call	MIOS_MIDI_BeginStream

.....

;; --------------------------------------------------------------------------

;; simpler routine modified from CS_MENU_MBNET_Tx_SendEvent

;;  IN: slave target already in MBNET_SLAVE_ID?

;;      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

;; --------------------------------------------------------------------------

CS_MENU_MBNET_Tx_SimpleSend

;;	movff	CS_MENU_SID, MBNET_SLAVE_ID	; prepare transmission

	movff	MBNET_RETRY_NODE, MBNET_SLAVE_ID	; 1 or MBNET_RETRY_NODE?

	SET_BSR	MBNET_BASE			; EID[LH] always 0

	movlw	6				; ETOS=6

	movwf	MBNET_EID_L, BANKED

	clrf	MBNET_EID_H, BANKED

	movlw	0				; TOS

	call	MBNET_Tx_Prepare			; returns pointer to DLC of Tx buffer in FSR1

	bnz	CS_MENU_MBNET_Tx_SimpleSend_End	; skip if slave not available


	movlw	3				; 3 additional byte to send

	movwf	POSTINC1			; DLC

	movff	MIDI_EVNT0, POSTINC1	; D0

	movff	MIDI_EVNT1, POSTINC1	; D1

	movff	MIDI_EVNT_VALUE, POSTINC1	; D2


	call	MBNET_Tx_Perform		; performs the transfer and waits for an acknowledge from slave

	skpz					; re-init display if transfer failed

	rgoto	CS_MENU_MBNET_Error


CS_MENU_MBNET_Tx_SimpleSend_End

	return

full code attached, I added a comment containing "(BB)" where I changed stuff. Also, there's a git repository in it if you like that. :-)

midibox-slidecontrol.zip

Edited November 7, 2010 by bilderbuchi

[TK.]

Wow, good progress! :)

Btw: there is a SVN repository available, see also http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2F

I just gave you programmers status - now you've access to a hidden forum section where you can post your SSH key to get write access to the repository.

(your .zip file doesn't contain all files, and the file structure is different for application development)

Inside the repository, you would simply branch the midio128 application and add your changes there.

Since you haven't included the cs_menu_mbnet.inc (and sid_mbnet.inc) file, I'm not sure if the transfer protocol is used correctly.

It's important that the slave replies a message, the master will wait for this!

And just to ensure: All sent frames must be visible on the Rx pin as well - even the sender must "see" the frame he is sending (for collision detection).

See also http://www.ucapps.de/midibox_sid/mbsid_v2_communication.pdf

Note that for longer distances between the cores you will need a CAN transceiver at each side!

Best Regards, Thorsten.

[bilderbuchi]

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...

Edited November 7, 2010 by bilderbuchi

[bilderbuchi]

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:

Edited November 7, 2010 by bilderbuchi

[TK.]

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.

No, you don't need to include these files, it won't help.

I missed mbnet.inc, and thought that you forgot to add other files as well...

@ 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).

Yes, but if you made anything wrong (e.g. diode in wrong direction, bad soldering joint), you would see such effects as well. Therefore this assumption...

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...

I don't have more explanations for this effect yet.

If you would work on a MIOS32 application, I would propose to add some debugging messages sent to MIOS Terminal, e.g. at the location where a new frame is sent, where it is received, where a reply is sent, where the reply is received... but MIOS32_MIDI_SendDebugMessage isn't available for MIOS8.

Instead you could debug with MIDI events.

E.g., send "B0 00 <any-number>" at interesting locations to get some hints about internal operations.

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...

No, I tried it with my Ubuntu installation some time ago, but it wasn't possible to send/receive MIDI messages.

This seems to be related to the Juce version that I was using at this time, but I haven't continued debugging in the hope that a Linux expert could solve this.

Best Regards, Thorsten.

[TK.]

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:

as mentioned before, it isn't really required to include cs_menu_mbnet.inc

I was only confused about the missing files.

Meanwhile I noticed that you added mbnet.inc to include/asm instead of src/ - thats the wrong location, include/asm is normaly copied from http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Finclude%2Fasm%2F and will never be touched.

It would be better if you would work with the original repository... ;)

Best Regards, Thorsten.

[TK.]

While looking into your mbnet.inc modifications I noticed that you commented out some important stuff, such as:

CS_MENU_MBNET_Tx_SendEvent

;;      movff   CS_MENU_SID, MBNET_SLAVE_ID     ; prepare transmission

[/code]


this will lead to an undefined ID - probably the master will send to any slave, but not to the slave you wanted to address


there might be more errors.


Best Regards, Thorsten.

[bilderbuchi]

No, you don't need to include these files, it won't help.

I missed mbnet.inc, and thought that you forgot to add other files as well...

ah, great. :-)

Yes, but if you made anything wrong (e.g. diode in wrong direction, bad soldering joint), you would see such effects as well. Therefore this assumption...

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.

Instead you could debug with MIDI events.

E.g., send "B0 00 <any-number>" at interesting locations to get some hints about internal operations.

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.

No, I tried it with my Ubuntu installation some time ago, but it wasn't possible to send/receive MIDI messages.

This seems to be related to the Juce version that I was using at this time, but I haven't continued debugging in the hope that a Linux expert could solve this.

thanks for the heads up. unfortunately, i don't think i'm expert enough.

While looking into your mbnet.inc modifications I noticed that you commented out some important stuff, such as:

CS_MENU_MBNET_Tx_SendEvent

;;      movff   CS_MENU_SID, MBNET_SLAVE_ID     ; prepare transmission

this will lead to an undefined ID - probably the master will send to any slave, but not to the slave you wanted to address

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.

there might be more errors.

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. :-(

Edited November 7, 2010 by bilderbuchi

[bilderbuchi]

While looking into your mbnet.inc modifications I noticed that you commented out some important stuff, such as:

CS_MENU_MBNET_Tx_SendEvent

;;      movff   CS_MENU_SID, MBNET_SLAVE_ID     ; prepare transmission

this will lead to an undefined ID - probably the master will send to any slave, but not to the slave you wanted to address

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:

Edited November 7, 2010 by bilderbuchi