Proper way to joint two AWG 28 wire together ?

Yaakov

Joined Jan 27, 2019
3,192
What do you mean about home runs system ?
If you use a bus, you can create a loop that serves the sensors and reduces the number of wires that must return to the cabinet. A "home run" means the wires runs for the sensor all the way back to the cabinet.
 

Thread Starter

meowsoft

Joined Feb 27, 2021
367
If you use a bus, you can create a loop that serves the sensors and reduces the number of wires that must return to the cabinet. A "home run" means the wires runs for the sensor all the way back to the cabinet.
What do you mean wire back sensor ?, for example LDR only use two wire one connected to micro-controller GND one more to micro-controller digital input, no intermediary controller that can use RS485 or something, that's very native sensor
 
I see an unorganized mess. My Chemical Engineer co-worker said, why does the wiring have to be neat? I was supposedly taking too long. I said so you can fix things down the road.
 

BobaMosfet

Joined Jul 1, 2009
1,786
What I might do is to put RJ45 connectors on both ends and use a coupler. Make sure you get the RJ45 connectors for both solid and stranded or the one used for both.

https://www.thebroadcastbridge.com/...4-awg-26-awg-and-28-awg-network-cables-differ

A 110 punch down block https://en.wikipedia.org/wiki/110_block might work, but I don't know if it;s OK for stranded wires.

I'd say solder and adhesive heat shrink but 200 connections, no.
A 110 block is perfect. Normally you use solid-conductor, but if you tin the ends of stranded, you can punch those tinned ends in like solid.
 

Yaakov

Joined Jan 27, 2019
3,192
I understood perfectly. I didn't make my point clear. I was suggesting you designed a number of small boards that can take analog or digital (like the switch) sensors, process the signals from them, then send the results as data to the MCU.

Each sensor would have a board with some very small MCU on it, perhaps an ATTiny that would produce the data and a serial transceiver to send the data back to the MCU. The MCU could poll sensors for the data or you could use some sort of TDM scheme where each sensor has a time slot to report.

Sensors could also use interrupts in those cases where it was needed.

I know you are not going to do this so don't tell me that you aren't, or why. I just wanted to make it clear to you that I understood what you were saying from the very beginning, hence "if you are stuck with home runs".

Frankly, and really in a friendly way not to insult or upset you, the architecture you are stuck with is really bad and someone needs to convince whoever is in charge that it is not sustainable. But, whatever, I would suggest you get out of there as soon as you can manage it.
 

Thread Starter

meowsoft

Joined Feb 27, 2021
367
I understood perfectly. I didn't make my point clear. I was suggesting you designed a number of small boards that can take analog or digital (like the switch) sensors, process the signals from them, then send the results as data to the MCU.

Each sensor would have a board with some very small MCU on it, perhaps an ATTiny that would produce the data and a serial transceiver to send the data back to the MCU. The MCU could poll sensors for the data or you could use some sort of TDM scheme where each sensor has a time slot to report.

Sensors could also use interrupts in those cases where it was needed.

I know you are not going to do this so don't tell me that you aren't, or why. I just wanted to make it clear to you that I understood what you were saying from the very beginning, hence "if you are stuck with home runs".

Frankly, and really in a friendly way not to insult or upset you, the architecture you are stuck with is really bad and someone needs to convince whoever is in charge that it is not sustainable. But, whatever, I would suggest you get out of there as soon as you can manage it.
Yes... that architecture is very bad... but it can't changed that... because that was my client request... and was described in contract
 

Thread Starter

meowsoft

Joined Feb 27, 2021
367
Very frustating architecture and also isn't good, yes my plan in have micro-controller in each room, and then connect all micro-controller by ethernet with carrier grade switch, and all micro-controller input output is monitored and managed by single board computer, so... that micro-controller is passive only act as I/O devices under SBC as a server, software API; also software user interface is separated in workstation server (web-based) and CCTV DVR also data record (I/O history, alert history, ...), I was try that in my home and all run perfectly, but isn't cheap
 
I was try that in my home and all run perfectly, but isn't cheap
What's the price of "failure"?

Define "Failure"?
Lost lives when it doesn't work?
Lost time when it's broken?

These axioms served be well, but I don't think they were appreciated.

1. When I fix something, I didn't really want to see it back for the same problem.
2. When I built stuff, I tried to keep the "appliance" concept. Use able elsewhere either torn down or together.

When I designed software and hardware to some effect, I would list all the features I wanted, or I anticipated "they" wanted if I had infinite resources?

What features must I have?

It might not cost much to code a "hook" in place. It would cost a lot of time to re-write.

An example: I had a file of parameters before XML was even invented.

Skip 4
Version 1.1
Parameter A, amps=5
Parameter B, volts=10
I(ma), V(V)
10, 1
11, 2

Something like that.

the program that wrote the data, wrote it in a specific order. The same program could read Parameter A and Parameter B in any order in the file.

Skip pointed to the (x,y) data.

The file format never changed. One program lasted 17 years before an upgrade. The new program, who knows, but it had the same data format.

I came up with the wierd idea and it could be done in FORTRAN.

Devices were written as device drivers. One entry point is "write defaults" and say "read defaults".
Write was easy. Just write a line to a file and when all of the units (similar devices) were written return.
Read was quite unique. It would read data until it was not for that device and then set the next read to the line that didn;t belong to the routine and exit.

For calibration, I decided on nominal and fudge factors. If 0-5V was 0-40V you would have gain and offset parameters to deal with.
5V
Nominal output 40V
Gain = 4
Fudge (0.94)

It meant that 4.7 V read was 40V. It was a lot easier to keep track of. The fixed 1% resistive dividers would be guaranteed never to exceed 5V so 5V -2%

There was this one project that was very odd: I had an idea how to design some Kelvin probes. Dual probes to the same contact pad. I was able to obtain enough parts to do a "proof of concept", but in the end it was a series of steps to improve the design and I did end up with custom tooling to make them. I eventually ended up with a magnetic low profile, high temperature, and room temperature versions and vibration clamps. There was a totally unique non-magnetic high temperature probe/high vibration probe as well.





The program w
 

Thread Starter

meowsoft

Joined Feb 27, 2021
367
What's the price of "failure"?

Define "Failure"?
Lost lives when it doesn't work?
Lost time when it's broken?

These axioms served be well, but I don't think they were appreciated.

1. When I fix something, I didn't really want to see it back for the same problem.
2. When I built stuff, I tried to keep the "appliance" concept. Use able elsewhere either torn down or together.

When I designed software and hardware to some effect, I would list all the features I wanted, or I anticipated "they" wanted if I had infinite resources?

What features must I have?

It might not cost much to code a "hook" in place. It would cost a lot of time to re-write.

An example: I had a file of parameters before XML was even invented.

Skip 4
Version 1.1
Parameter A, amps=5
Parameter B, volts=10
I(ma), V(V)
10, 1
11, 2

Something like that.

the program that wrote the data, wrote it in a specific order. The same program could read Parameter A and Parameter B in any order in the file.

Skip pointed to the (x,y) data.

The file format never changed. One program lasted 17 years before an upgrade. The new program, who knows, but it had the same data format.

I came up with the wierd idea and it could be done in FORTRAN.

Devices were written as device drivers. One entry point is "write defaults" and say "read defaults".
Write was easy. Just write a line to a file and when all of the units (similar devices) were written return.
Read was quite unique. It would read data until it was not for that device and then set the next read to the line that didn;t belong to the routine and exit.

For calibration, I decided on nominal and fudge factors. If 0-5V was 0-40V you would have gain and offset parameters to deal with.
5V
Nominal output 40V
Gain = 4
Fudge (0.94)

It meant that 4.7 V read was 40V. It was a lot easier to keep track of. The fixed 1% resistive dividers would be guaranteed never to exceed 5V so 5V -2%

There was this one project that was very odd: I had an idea how to design some Kelvin probes. Dual probes to the same contact pad. I was able to obtain enough parts to do a "proof of concept", but in the end it was a series of steps to improve the design and I did end up with custom tooling to make them. I eventually ended up with a magnetic low profile, high temperature, and room temperature versions and vibration clamps. There was a totally unique non-magnetic high temperature probe/high vibration probe as well.





The program w
No... Expesive isn't a problem, my principle is do all the best, if there is any cheap solution always choose the most expensive, even in main feeder when requirements is only 95mm² we use 240mm² for main feeder, we ensure all project's is reliable and everlasting, we calculate if wire capacity is reduced bt aging after 16 years so our rules is 250%-500% wire capacity from continuous load, against 125% rules by US NEC, except is client need's cheap solution, but we not accept that type of customer again, also we ensure all component's we buy is very expensive and very good, we install 120a 36v power supply event requirements is only 25a 36v
 

Thread Starter

meowsoft

Joined Feb 27, 2021
367
Principle : "always be most expensive, most everlasting, most safe, also the best quality and no wasting money problem, all of our service is guaranted be functioned properly after 20 years of operation"
 
Top