Hello All ,

My name is Roland, I am new on this forum and I write from Belgium.

I read those topics but it not quiet clear for me.

I am also a beginner with digital.

Please help me by describing step by step how il is possible to programm the m83 to make a bliking light for exemple.

Marklin's french documentation is very poor!

I see the video given here above on youtube. How is it to obtain this result? That seems so easy for you!

Sorry for the language mistakes but normally I speek french!

Thank you very much for the answers.

Best regards

Roland

Hello Roland,

Can you please indicate the controller you are using - this will allow for a more focused reply.

Roland,

With a CS2 you may use either
- Programing Track (Read and Write)
- POM (Write Only)

The Program Track (PRG) may be used with either a dummy DCC loco , or (post v3.6) the Keyboard edit function.

See if the following helps join the dots - it is for POM, but you will see where that is selected and you can use PRG instead if desired.

Martin,

I have not explored (stress) testing this aspect.
You do not state the power available from your 21VDC line.

As originally identified, the external power could be provided via Marklins 66361/5 only - this is an 18V power supply
At announce it has been stated that the power supply cannot be used without an intermediate 60822.
The reasons for this remain unclear

We also know that the track voltage is 22V peak (square wave AC)
Thus , a tolerance to your 21V option might well be expected
I will comment that the 60831 does appear to be "short of power during programming" when being connected to MS2 track power only

Of concern would be "where is the fuse". Is there fusing within the 60831 or is this why the 60822 is needed.
If the fusing relies on UV monitoring under load, then detection may be suspect with a higher (than spec'd ) input.
The 3A notation in one database is unqualified - and certainly not achievable currently as the 66361/5 is 18V/36VA = 2A (max)

I welcome your testing results, however am inclined to await the delivery of the 60822, with a view to understanding what purpose it plays in power delivery/protection.

Real 60822 came up on ebay.

http://www.ebay.de/itm/M...6787?hash=item43e0d29863

Scroll down for more pictures.

From information to hand about the 60822 (Marklin have still not published a manual on their website)

From what I can gather there is still nothing to actually specific to indicate what it does. i.e. Why call it a power supply when you need a power supply to make it work. The reference to an Overload LED is the only hint I can see.

Refering to the photo in the ebay link provided above.
2)
2b) the right hand "D9" connector , metal edge just seen = "no function"
2a) the left hand "D9", not visable" = .. is intended for direct connection for a m83/m84 decoder.

1) The right hand end "DC barrel connector" (next to the D9 connector)is the "Connection socket for the 66361, voltage supply"
- Safety Notes "The voltage Supply for the Power Supply Unit comes exclusively by means of the 66361 switched mode power pack"
CONFLICTING but expected
- Electrical connection: The 60822 ... from 60361/60365 ..."

3) the green (2 position) terminal block at front right = "for connection to the track layout" ?? TRACK ? presumably the input Red/Brown from track OR controller/booster
6) the red LED next to the terminal block - overload indication . Now we get a hint of the real purpose !!!! But No actual specification for what value this overload value is. The 2014/5 Catalogue alos makes a note to "... note the maximum power limit" also, without stating what its value is

4) the green (3 position) terminal block at front left = " for k83 decoder"
5) the green LED next to the terminal block - "status indicator" - shows when the device is supplied with voltage.


k83
Older k83 decoders can also be supplied with power with the 60822 Power Supply Unit
These are connected to it according to the graphic........

Along with the "0" and "B" going to the k83s Brown and Red ...
??? The Graphic shows the "L" plugging into a Yellow of one of the k83 outputs. "" ???
PLUS a graphic that stresses do not use (with the k83) concurrently with a ("b" or "0") connection to the track.

Comment/Supposition/Guess ,...
That the "B"/Red is only the + (positive side) of the digital square wave. and the "L" is rectified - (minus) 22V
Thus preventing the k83 from producing its own -22V


Closing thought:
- The reference in the 60883/L88 to ... Current supply 66361+ 60822 would appear to be a typo as there is no "D9" connector for it to get its power from.

- There is apparently no active components in the unit with just Capacitors,Resistors and Diodes(LEDs) along with one Inductor (Power Choke) and a V1 (possibly varistor)
Therefore The overload is just an indicator - no actual cutout.

- One past reference did allude to the power input possibly being able to be supplied from a normal (Marklin) AC transformer, and the unpopulated "K2" designation (seen in the image) does have land-patterns/tracks to a missing BR1 (which can be logically assumed to be a Bridge rectifier) because its output goes straight to the DC connector and has a big Capacitor across it. Thus, with these components missing, this promise for ROI of old blue transformers is unfulfilled.

Søren,

I am unclear on what you mean by "get through". The 60822 is a power supply/power filter for the M8x

It does have a separate track input (B&0) for use with (.. pass through to..) the K83 , (i.e. if you do not have a any M8x ). However, as per the 60831/41 manuals, you do not use this 60822 B&0 connector for the input for the M8x devices.

Yes, I know. With regards to the digital connection, the 60822 manual states, at least my manual does, and shows with a drawing: "The digital signal can be connected from the track to the 60822 Power Supply Unit. Additional power feed to the m83 / m84 decoders connected to the Power Supply Unit are not necessary.".

The drawing in the manual shows the digital signal connected to the 0,B port on the 60822 and m83 / m84 decoder connected to the side with no connections to it. If you do that with more than one m83 / m84, all the decoders in the row stops working. By "getting through" I meant that it seems like the digital signal does not get through to the decoder, since the decoder stops reacting, the power does get through though. First I thought it was the overload protection in the 60822 that was somehow failing, but everything is powered and the overload lamp is not on.

To sum up: If I connect power to the 60822, and connect the digitial signal to the 60822 and then connect one, and only one, decoder m83 / m84 to it, it works just as expected. If I connect an additional m83 / m84 or more, it stops working. I have heard a few people, and one dealer, complaining about this, so I wondered if this happens to everyone.

If I drop the 60822 and the power source completely and feed the same decoders directly using just the digital signal connected straight to the first m83 / m84 in the row, the things work just as expected and everything is good.

Something happens in the 60822 that can cause this behaviour, and I really cannot see what that should be.

To be pedantic, the m83 has 8 ports - these are usually utilised as 4 "pairs"



- Use ports 4G and 4R so CV's..
- - 130,133 = (mode) .........= 17
- - 131,134 = (PWM ) .........= 255 <- ( may be tweaked down to about 128 for speed control - depends on motor )
- - 132,135 = (duration) .....= 250 <- ( x 0.05 = 12.5 seconds )



Port pairs 1 to 3 (CV 112-129) may be used for whatever else you have - solinoid turnouts/signals .....
As individual ports you may use them for uncouplers or just LEDs (with features like flashing)






My question to you ....

What are you actually using the 60821 for ????
Or more specifically which motor are you using ?

Seems that m83/84 have still some mysteries...

18 "detects" end stop cutout and stops driving power to the turnout
For functional use with a "good" 74491. But quite OK for those without cutout switches - just set a realistic period

Summary - leave the m83 with its defaults ....





Pulse width is just a geeky way of saying "brightness" or "% of power"
By varying the PWM value from 0 to 255 you
- vary a lamps brightness from 0 to 100% (of the available maximum)
- provide a weaker or stronger "oomph" to your turnout motors.

The inference being, that M-Track mechanisms are not as efficient as C-Track mechanism...
However this may also be perceived as a "work around" for C-Track mechanism failures with
- poorly designed "bounce back" detention. Less power means less chance of bouncing back and leaving the tongue in an intermediate state.
- underrated end cutoff switches. Less power MAY reduce the amount of contact arcing causing totally failure of the switch. The logic here is that any AC pulse must pass through "0" and thus facilitate the suppression of continued arcing.

for 30% of 255 use a value of 80.
But I suspect you are better of leaving it at the factory default of 100%(i.e. 255) to remove confusion, and address the turnout motor issue directly.

If you had a newer 74491 with 2 working end cutoff switches - you may want to use Mode 18

Period relates to the duration of the 'overall' pulse to the device.
(During the period, the actual signal may be pulsing to give the appropriate brightness/power)
OR
if you were using one of the fancy non-solinoid functions like Blinking, MARSing, etc. then the period is the duration between each blink.
For the florescent emulation the period is the time it splutters before settling to "ON". For Zoom it is the time to fade on and fade off.

Typically this has been around 1/5th to 1/4th of a second (200-250ms) for a device with a magnetic/solenoid device.
- In the 6021 days you could just hold your finger down longer if you wanted a device to energise longer (good example was an uncoupler)
- with the CS2, the controller definition for an individual accessory address could define and the period (energised) time. HOWEVER this doesn't stand up in practice


Switcing Function
Sticking to just the solinoid modes of ...
- 16 = Max. switching : “Period“ indicates the max. switching time
- 17 = Min. switching "“Period“ indicates the min. switching time
- 18 = "Min. switching with end switch Switching time is “period“ or until the end position is reached
... we need to understand two separate aspects.

1) The turnouts with end stop micro switches will (should) cutout the power to the solenoid when the end is reached. On the face of it, it is logically that if the controller m83 can detect this then in should stop wasting any more energy driving the port.
This is what Mode 18 offers.
This is most noticeable in testing, if you have nothing connected to the port - no mater how long you extend the period for, the observed pulse on the LED associated with the port will be seen for a very short time. (it turns on, determines no load, turns off)

NOTE: as per comment above aboult real world "bounce back" - in cases where the bounce back causes the end switch to make again then it WOULD be good to have the drive energy still available to correct -BUT this is not actually how the 74490 works

2) Controller defined period (and its override).
Please understand here that a CS2 "currently" will send a "turn on" and "turn off" pair of commands regardless. e.g. "Address 83 Red, please energise" and then a "Address 83 Red, please de-energise". While this may offer more variation in what the CS2 can offer, it does mean that, for a majority of cases, it is wasting valuable processing time managing the timing and transmission of a followup secondary command.

To offload this function the delay handling may be delegated to the m83...

PLEASE NOTE THIS IS MY INTERPRETATION OF WHAT I BELIEVE THE M83 IS TRYING TO ACHIEVE.
BECAUSE OF THE WAY A CS2 GFP WORKS THIS JUST IS NOT ABLE TO WORK FULLY
BUT EVEN TESTING WITH A 602x CONTROL WITH SPECIFIC ON OFF COMMANDS MY CURRENT M83 DOES NOT PERFORM FULLY AS DOCUMENTED

THE MOST NOTABLE EXAMPLE IS THE INABILITY TO HOLD THE UNCOUPLER BUTTON DOWN WITHOUT IT PULSING

Mode 17
In some cases it is just convenient to say to the m83 "please pulse" and leave the m83 to do the work. This is where the mode 17 "Should" come in. A quick energise/deenergise will cause the m83 to start the pulse to the addressed port (e.g. 83Red) and use its own timer to define how long the pulse is actually on for.

BUT note the "Min Switching" reference.
What this "Might" mean is that IF the CS2 delays its "deenergise command" such that it is after the m83s period setting the port will STAY energised anyway.
One example of possible usage here would be an uncoupler, where you hold you finger on the button for an extended period, while the train moves into position.

The only flaw in this ideal, is that the CS2/m83 does not actually work this way (I actually believe it is BOTH a CS2 and a M83 issue (bug) ).
From my observation it is probably the CS2 is not playing the game, as it insists on sending a double energise/deenergise comand anyway AND if your finger is still on the button it just sends repeated PAIRS of commands so you end up with slow pulsing.

I do note that the software programming reference for the CS2 does provide commands to modify the GFP behaviour in the area of accessory usage.
But as far as I am concerned if you cannot achieve this with the UI it is impractical to pursue.

Mode 16
(Should be) Similar to 17 but with the emphasis on the "Max switching" rather than the min switching.

As above, because the CS2 insists on sending its pair of pulse, it is not possible to see this in operation as the CS2s command (pair) is always shorter than the Period setting (unless your eyes can detect the difference of a pulse down to 5ms).
That said, Even the 602x environment can't achieve/use this.


If anyone has a test case which does show these functions working as documented, I would love to hear them.

I am only reporting what has been gleaned from available documentation and my observations.
Generally I am open to permutations I may have missed or not been able to test, however I am not aware on any additional or qualifying information.

As to Why? .....
Speculation offers some mental stimulation for a short period of time. But after over three years since product announce, I really don't care anymore.

Hallelujah


60832 Manual available
http://medienpdb.maerkli.../1/pdf/60832_betrieb.pdf
dated 283054/0317/Sc1Sh

While being just a piecemeal extension to the 6083 manual (no updates relating to 66360 power supply for example), the mfx capability is accompanied with a CV79 to allow succinct control of the 8 ports individually
NOTES:
1) CV79 is NOT tied to the mFX function. It just becomes available at the same time and can be set with MM/DCC
2) The CS2/3 templates do not show this CV, even though the recent CS3 update (v1.3.0(0) ) "Change Log" alluded to an update in this area

Comment : Limitations as documented are that all 8 ports operate with the same type of function
However Mode 3 states "Random AND Blinking", indicating that there may be a sub parameter available
I am (forever) hopeful that this translates to being a way "initially" set/reset all port modes but subsequent changes to the individual ports CVs will be possible. i.e. don't change CV79 again unless you want to overwrite changes made to individual ports.
If logic was to prevail this would simply mean that CV33 could have a value of 4 or 8.

Other technical information coming to light is the 200mA rating of each output. As per previous observations 200mA x 8 is 1.6Amps which occupies the bulk of a 66360 capability.
Therefore if you are likely to uses 200mA per port AND they are likely to be all on ... you cannot chain 2 m83s together - each would need its own power supply. (I suppose the extra might be sucked from the Red/Brown track supply , but that is getting deep)


CV 79 – Preset Operating Mode
With the preset operating modes, it is possible to move the decoder into a pre-defined operating mode without having to program all of the CV variables individually. The decoder then operates as building lighting, street lighting, etc.

Mode 0 (Value 0) – Standard Mode
In this mode of operation, the decoder occupies 4 addresses.
This is the mode as delivered from the factory. It is used to control 4 solenoid mechanisms with an end shutoff feature.

Mode 1 (Value 1) – 8 Switches, 4 Addresses
In this mode of operation, the decoder occupies 4 addresses.
Switching the outputs is done by means of momentary buttons (same button for on and off). An output is controlled by the red momentary button, and the green momentary button controls the second output.

Mode 2 (Value 2) – 8 Switches, 8 Addresses
In this mode of operation, the decoder occupies 8 addresses.
Switching the outputs is done by means of red/green buttons. Red switches the output off and green switches the output on. The brightness of the output can be set by the parameter dimmer. The period has no function.

Mode 3 (Value 3) – Blinking and Random, 8 Addresses
In this mode of operation, the decoder occupies 8 addresses.
Switching the outputs is done by means of a red/green button. Red switches the output off and green switches the output on. The decoder executes various blinking functions to simulate flickering lights or warning lights.

Mode 4 (Value 4) – Neon Street Lighting, 8 Addresses
In this mode of operation, the decoder occupies 8 addresses.
Switching the outputs is done by means of a red/green button. Red switches the output off and green switches the output on. This mode simulates the starting of neon tube lights. The brightness of the output can be set by the parameter dimmer. The period determines how long the flickering of the light tubes coming on lasts.

Mode 5 (Value 5) – Energy Saving Lighting, 8 Addresses
In this mode of operation, the decoder occupies 8 addresses.
Switching the outputs is done by means of a red/green button. Red switches the output off and green switches the output on. This mode simulates the starting of energy-saving lights or pressurized gas lamps. The brightness of the output can be set by the parameter dimmer. The period determines
how long the fading in of the lights lasts.


Now to wait and see how it actually works in practice.

Comment:
No comment about firmware levels that might indicate the 60831 is updateable. My 60831 with version 17 will not permit writing to CV79

Ref 60832 manual page 20
"Operation with mfx"

This section/paragraph has a very brief introduction that mirrors the mFX signal products methodology for discovery. But is short on specifics.
In fact the reference to the CS3 "Search for mfx item" belies a reference to an ancient CS3 version - Currently @ 1.3.0(0) this reads "Discover mfx itmes"

Re: Note about mfx registration with the CS2
This correctly highlights that it is a CS2 global setting that determines if a newly discovered mfx item gets a new address or is allowed to retain its DIP switch address (even if it conflicts)
For comparison the CS3 discovery offers a prompt for this decision as you start each discovery. Note: it asks this up front, before it has attempted the scan, so it is not implying that it has detected a conflict.

Auto-configuration wise, not spelled out is that a signal has a (product) code to assist the CS identify what it is (Light/Semaphore , 2,3,4 aspect etc)
For the 60832 you may be detecting the "box" but the ports themselves are up to the user to define
Comment: Like the mfx Signal configuration for light fading/arm bounce, this really could be done a lot "friendlier" than having to type numbers into the correct holes.

One aspect that is discovered at the box level is the number of ports 4 or 8.
For non mFX user there is no reference to the work around handling of the m83.2 when in 8 port mode.

For now, until there is a CS update, the keyboard must be defined as two sets of 4.
As such, the DIP switch pictorial looses its integrity.

Comment: Marklin may like to take the opportunity to leverage the mFX discovery function - delaying a CS update for legacy support. However if the legacy support is not catered for and there is an integrity issue with what is shown , it should be commented on in the manual at the very least.

Full support for the mfx configuration (registration) of the m83.2(60832) with a CS2 is still pending an update (expected?)
(This may come when when the long anticipated 32 function support is ready.)

Both the CS2 and CS3 CV template config files provided by Marklin have shortcomings, but unlike the mfx method you can create/modify your own files - or just write the CVs without a template file.

As per prior items, neither file has an English variant.

At this juncture, with the m83.2 (60832) and m84.3 (60842) recently available purporting mfx support, I think it is important to reiterate that mfx needs two to tango.

While a mfx device may respond to queries with codes and values, the control station needs to have an external awareness of what those codes mean before it can present information in a constructive manner.

Right now , neither the CS2 not CS3 fully support the 60832/60842 registration or configuration. and what is available is piecemeal requiring reediting and workaround jumps from one place to another.

For example.
Unlike the mfx signals , where the product code defines the type of signal face to use, in its most basic form the CS3 registers all four ports of a 60832 as "left turnouts".
The CS3 accessory configuration edit screens make it laborious to edit the icon quickly (e.g. for signals), as it subsequently presents only turnout options as alternatives, until you first delete it (no article) and manually go through the process to add a new one anyway (selecting existing decoder as needed).

While functional, this hopping around is just unwarranted and a hindrance to operator enjoyment.
* It would be desirable to have the registration wizard ask these questions as as the unit was being discovered.

For the more advanced (8 address mode) the registration just has no concept, you have to dummy up the second group of 4, and if the original registration has picked a gap with something already after it - then even more reediting is needed.
* As above, the wizard should prompt for this information as part of the registration making things far more , meaningful, efficient and enjoyable.

Note: There is a CS3 bug with a new registration attempting to "wrap around" an existing lone item (e.g. mfx signal)
* Do not use the "Get a New Address" when doing a mfx discovery

The "output" configuration panel has huge potential, but one has to wonder why "Smoke" is an option (using mfx block 6, instead of a modified block 11)
* This is the type of friendlier presentation that is needed - HOWEVER retaining the geeky numbers of 0.05 seconds and ratio of 255 is not helpful. It is simple to just ask for the "# of seconds" or "percentage" and do the geeky work in the background.

In summary,
By all means explore and experiment to your own interest level needs
But - until there is major improvement in the CS user interface both cosmetically and ergonomically ...

If you are just needing a m83.2 for its k83 capability
a) use the dip switches for address
b) and create the icons in the traditional MM or DCC

If you do want the advanced "mode" options
a) use the existing DCC CV configuration - to set the "mode" (CV 33 = 4/8 = number of addresses) and then the port level characteristics
b) and create the icons in the traditional MM or DCC

Workaround for 4 port toggling

Provided you are prepared to accept the involvement of a PC. - a workaround exists to cater for the toggling of individual ports when the m8*.* is in 4 address mode -

In 4 port mode, ports may only be toggled from the CS - e.g. press the "1-Green" button once and the port one turns on, press it again and it turns off.
While the human eye/brain may compensate for this, there is no way for a memory sequence to know if a port is already on or off.

The solution arises because configuration with DCC POM and now (60832/60842) MFX may be done dynamically without affecting the other ports on the unit
(This compares with using the programming track in either DCC/CV or MM/REG modes, which does cause the whole unit to reset and blink as either a read or write is done)

What is possible is - Not to turn a port on or off, but to permanently leave the port on - AND then change what "ON" actually means.
This might be either the Prime function mode, the PWM value (Brightness) or Period (if applicable), and can be done by issuing a dynamic configuration command.
Note: Of course the same can be done using the configuration panels, but you do not want to do that every time a light is to be turned on or off

via the PC, using a DCC command is easier to construct than MFX as you can directly address the port(m8x lowest port) without having to lookup and translate a MFX ID(Serial number) to its effective address.

As an example ...
- sending a configure command for mode of 128 will simulate "Off" and a 129 "On" (Dimmer)
- or you may leave the function alone (i.e. 129 = Dimmer) and play with the brightness using 0 or 255 to produce Off and On respectively.
This option immediately opens the possibility of setting multiple interim dimming settings.

In practice a PC program could have a button that you click on, that then sends the commands
OR
It might be set to monitor (sniff) a different proxy address from the CS and when its detects specific Red/Green commands , translate these to brightness=0(red) or 255(green)
By doing the later, the PC program runs in the background and you maintain control at the CS.

Other possible uses
- variation in dimming levels
- change a light from On (solid) to Blinking
- change the speed of a motor (using the 60821)
- servo
- adjusting the period of a blink (from slow to fast)
- facilitate using a single m8*.* device for traditional devices (point/signals) on some ports while using the others individually (for LED lighting).

Excellent work Peter and Ross

Very interesting and high quality information first from Peter and then A great and illustrative PDF from Ross.

I really appreciate this type of work and its information

I hope you will continue to do this kind of research.

Regards

Jukka

Hi Peter/All,

I'll comment below to your comments but first I must say I like your engineers look at the Märklin system components.


I'm glad you liked the article and videos as you know it takes an enormous amount of time to put together.


Since I have intergrated the signal tower into my layout I have noticed getting the sync or out of sync flashing is affected by how busy the digital traffic is on the central unit. It is sometimes noticeable that the sync isn't correct.


I have multiple boosters feeding my layout where all m83/m84 components are kept separate from any track boosters.
I agree that solenoid turnouts and signals need to be separate from the m83 light switching circuits.
Where did you get the figure 0.5amp load for each port?


On the ECoS the switchboard for switching points, signals and lights isn't flexible enough. Each switchboard has 16 slots (4x m83/k83) and if we want to only switch the red or green port of a m83 for lights there isn't a symbol for a pulsed duration that can be represented in one switchboard slot for the red/green port that gives clear indication of the state of each port. I see a 3 way point expand to show all switch options it would be nice the have the same for red/green ports to switch lights and uncouplers.


All commands from the ECoS can be monitored in TrainController by some method.


I don't think that the m83 was designed to dynamically change values without affecting the entire m83. POM is possible but first you have to select the correct m83 module then once you start programming a port all other ports switch off until programming is complete and as the m83 doesn't have a memory all ports would have to be switched back on to their last known state.

I don't know the CS2/3 architecture but as long I can control my trains in an easy manor I find I'm less reliant to favour one brand over another.

Keep up the good work Peter.

This is not borne out by my observation.

While using the programming track for REG(MM) or CV(DCC) configuration does cause the unit to reset as you describe, using POM or mfx reconfiguration does not impose this problem and only affects the addressed port witin the unit relating to the CV.

This is irrespective of whether an external power supply is powering the m83 or not

A small video showing that changes to a single port can be done without affecting the other ports.



The point of this is not to do it as a manual function (labouriously navigating through screens) but to use the PC to issue the commands just as you would operating a normal signal/turnout accessory - slightly different command codes of course to invoke the DCC POM (or mFX)

Disclaimer - at least not on my CS, I do not have an ECoS to compare.

Reminder: This sub-topic is aimed at the m83.1 (60831) which does not have 8 port addressing capability

Edited by user 29 June 2017 03:49:00(UTC)  | Reason: Not specified

Personally I do not use a 60822. And am making fine use of my 66361's.

Marklin have not satisfied me with sufficient reasoning - or commitment
If they were serious about the assertion, there would be no power jack on the m8x full stop

Also, since the original m83/m84 GA'd, they have updated the 66361/66365 to 66360/66367 so if there was a techincal problem it should have been well and truly sorted out with these new PS and the new m8x designs.

In addition it means good ROI for the PS and MS2 from those starter sets only "needed" for their loco and stock

Yes - or mfx for the m83.2 (60832)

I have added a YouTube link to my last post. It simply demonstrates that a dynamic configuration can be done (in this case from a PC program) without affecting other ports.

The TCP and command protocol for the ECoS/CS1 is quite different from the CS2/CS3. I haven't revisited the CS1 in this exercise

From a PC point of view, sending the command for a reconfiguration to the designated m83 for a port should be a low risk (once developed and QA'd)

I have not pursued this angle.

Most laptop power supplies these days are either 19 or 20 v and meet the general power spec ...
BUT there is NO spec for the inrush/surge that is expected when pulsing a solinoid device