selfbus.org

Hello,
I built this actuator by connecting relays in place of the LEDs for manual control, avoiding the use of expensive bistable relays. Unfortunately this makes a good part of the sophisticated software written by the author useless. Considering that the original actuator is rather large, then it will certainly be placed in a box where you can install a small transformer to power the relays from outside, why not use a simpler electronics, with monostable relays powered externally and not from the bus , with reduction of PCB complexity and costs. If I wanted to change the code to directly drive monostable relays and not via SPI where do I have to intervene?

thank you

To change the relay switching for monstable relays you have to write a new Relay.cpp and Relay.h. Your class needs to provide those methods declared as public in the original Relay.cpp.
Additionally you need to modify RelayAndSpiProcessing() in app_main.cpp as this implements the SPI transmissions.

there is a lot of material in these files, probably almost everything is no longer needed, as the energy control process has no reason to exist. I would like to understand at least what is the variable that contains the information on the relay to be switched

The main characteristic of the relay-unit is that it can collect several switch requests which are then combined and enqued as one entry in a fifo. This allows to keep switch requests which are the result from one group telegram to be kept together. In this case, the relay unit would wait until there is enough energy to switch these relays at the same time. On the other side it has to be avoided to keep contradicting switch requests in the queue, so there is logic to look through older fifo entries to discard any of these requests. On the other end of the fifo entries are read from the fifo and switch requests are executed if there is enough energy available.

To map these functionality to variables and methods:

Switch(int no, bool state, bool forced=false);
Takes one single switch request and (temporarily) stores it in:
unsigned short NewMask;
unsigned short NewBits;

Several calls to Switch() will set new bits in NewMask and NewBits.

void DoEnqueue(void);
Transfers the colected switch requests to the fifo as one request. Before this the fifo is searched for any contradicting switch requests, which are discarded.

bool DoSwitching(unsigned time, unsigned &RelDriverData);
This method gets repeatetly called by the main loop. It looks at the oldest fifo entry and executes it, if enough energy is available. It can be configured if one fifo entry should be executed only if enough energy is availbale for all relays to be switched at once or if an entry is allowed to be split.

unsigned short ChTargetSwStatus; // Schaltzustände, wenn alle in der Warteschlange stehenden
This stores the relay state as a bit mask. This is the state as if all entries of the fifo would have been executed, the real state might differ.

unsigned short ChRealSwStatus; // Aktueller Schaltzustande der Relais.
This is the actual state of the relays as a bit mask.

I hope this helps.

thanks again, I will try to modify the project according to your directions.
Good job

Good morning Florian here I am again ..

It seems that it is possible to switch relays in the routine (Appl.cpp):

void Appl :: ChannelTrigger2RelaySwitch (intno, TStateAndTrigger & trigger)
{
 if (trigger.Sw)
 {
  bool RelState = trigger.SwOnOff;
  if (ReadChConfigByte (chno, APP_SW_NONC_O) & APP_SW_NONC_M)
  {
   RelState = not RelState;
  }

  // chno = channel number to switch
 // RelState = new relay status

  switch (chno)
     {
     case 0: // channel 1
         serial.print ("channel 1 ->");
  serial.println (RelState);
      break;
     case 1: // channel 2
  serial.print ("channel 2 ->");
  serial.println (RelState);
      break;
     case 2: // channel 3
  serial.print ("channel 3 ->");
  serial.println (RelState);
      break;
     case 3: // channel 4
     serial.print ("channel 4 ->");
     serial.println (RelState);
         break;
     case 4: // channel 5
     serial.print ("channel 5 ->");
     serial.println (RelState);
         break;
     case 5: // channel 6
     serial.print ("channel 6 ->");
     serial.println (RelState);
         break;
     case 6: // channel 7
     serial.print ("channel 7 ->");
     serial.println (RelState);
         break;
     case 7: // channel 8
     serial.print ("channel 8 ->");
     serial.println (RelState);
         break;
     default:
  serial.println ("unknown");
     }


  relay.Switch (chno, RelState);
 }
}

However I have some quirk to clarify, theoretically the actuator can command from 1 to 12 relays, appropriately defining #define CHANNELCNT x in config.h.
In my case, if CHANNELCNT> 6 it is almost impossible to program the device in ETS (5.6.3), in fact, after the first group address and application programming, in the following everything happens, for example the actuator locks in phase of programming bringing the absorption current to 20, 40, 60 mA or more.

Do I have to change other parts of the code to have more than 6 channels?

Thanks again

You might be running out of RAM or program flash of the microcontroller. The compiler will not notice this because not all memory sizes are known at compile time. And if this happens to be true, you will get strange malfunctions. The needed RAM is directly connected to the channel count.

The RAM:
The compiler knows only the static variables, any local variable in a function will be placed on the stack. Static/global variables are placed from the bottom up, stack will grow from the top down. If they touch, data will get destroyed.
If you look in the .map file you can check the various memory sizes. If you search for _pvHeapStart you can see how much static/global RAM your program needs (because after this memory area, the so called "heap" starts). At the original out-cs-bim112 I see an address of 0x10001cb4 (which means 0x1cb4 bytes of memory are used). At 0x10002000 is the top of the stack and it will grow downwards. If they overlap, the controller crashes. Unfortunately I do not know at the moment, you much stack the program will need. You might need to check with a debugger.

The program flash:
As stated in config.h, the program size must not exceed 0xEA00 bytes. If it happens, a data area for storing the actuator state will get overwritten which will most likely cause malfunction. You can check your program size either by looking at the compiler messages (size of the "text" segment) or by checking the map file. The line with __exidx_end contains the last program memory address used. Your program size will grow unexpecedly if you reduce compile optimization.

perfect, with your directions I got an apparently functioning 8-channel version. To limit the use of RAM I deleted the debug and relspy file (with relative .h) using 0x18a4 bytes of RAM and 37540 bytes of Flash. I would like to further lighten the program by eliminating the routines of energy measurement management, in consideration of the fact that it does not feed the relays from the bus but externally, but I'm afraid of deleting parts of the necessary firmware and therefore making the system unstable, even if not I get errors during compilation.
However, I must point out that it is not possible to completely delete devices via ETS, there are problems with deleting the physical address.
Thanks again for the availability
good day

hi, I'm back

I noticed a strange behavior in my modified circuit for monostable relays, perhaps associated with a pcb design error, because, sometimes, after a power failure the actuator is blocked and does not respond to any command and I have to reset the bus .
I assume that disturbances related to the restoration of the network voltage can block the microcontroller, but I am not sure that the original firmware was equipped with a watchdog, which in this case could reset the UC.

How can I set the watchdog (in flashmagic there is no trace)
thank you