CAN itself will only send up to eight bytes. Generally one uses some other protocol that's built on top of CAN, but that's specific to CAN underneath and whatever you need on top. Also generally, any such protocol will have a way of breaking a long message into smaller chunks for transmission, and reliably reassembling them at the receiving end.
There's a number of established protocols, each designed for a specific use. Depending on your needs you can use one of those outright, build your own protocol inspired by one of those, or just build a protocol from scratch.
I suggest a web search on "CAN protocols", or a good book. The two protocols that I (vaguely) remember are CanOpen and a SAE protocol that's specific to car applications. I don't remember enough, nor do I know enough about what you're doing, to recommend a specific protocol.
The CAN specification specifies up to 64 bits (8 bytes) of payload and an 11 or 29 bit identifier. In principle, you could transfer one resp. three additional bytes in the identifier, but then you could have only
8 resp. 32 different identifier in the whole bus.
So you might be able to transfer up to 11 bytes in a single message using the long identifier format.
However, this would make it very hard to use any normal CAN devices on the bus and it might also be hard to set the message filters on the receivers (depending on processor type).
I'd kind of like to see CAN expire in general. There are different versions of an Ethernet PHY that can replace it. For other domains, there's PROFIBUS, which is weird but at least supports variable length PDUs.
I am not familiar with CAN but I would like to see a standardized Ethernet connector for coaxial cable plus power pins (12V?). Have been dreaming of that for may be 25 years. Apparently there has been no interest. Nowadays as we have more RAM for buffer memory and they promote that IoT thing the necessity has eventually become obvious - hopefully...
CAN is ideal when you have a lot of small nodes with a few, say 16 binary or a few analog I/Os in a node. For other protocols you probably would have to use a concentrator/gateway and hardwire the nodes to the concentrator before going to some bus structure. With CAN it is economical to connect the small nodes to the buss directly.
This works great with a small network (less than 10 m), but things get hairy at 250 m or even at 1000 m with very low data rates due to the signal propagation delay.
The problem with Ethernet protocols is the requirement of at least 64 bytes total, so for most small I/O nodes, they do not even fill that minimum size frame.
One exception is EtherCAT ttps://en.wikipedia.org/wiki/EtherCAT in which the master sends out a big Ethernet frame, which then passes through each slave. Each slave picks the bytes it is interested in. It can also reuse a slot in the frame and insert input data into a free slot and finally the frame is passed back to the master, extracting all input data inserted into the frame during the pass through each slave. Of course, this requires specialized hardware in each node. The delay is only a few Ethernet bit times in each slave.
Think about a local train, in which passengers are leaving at each station and others will enter at each station.
At least Profibus DP is just glorified multidrop Modbus RTU on RS-485. with all the same issues with small nodes as with all request/response protocols.
Profibus is horrendous. It is complicated to implement, poorly documented, "open" in the worst sense of the word (meaning "anyone can pay lots of money to join a closed group that promises not to tell the rest of the world how bad the specification is). I had the "pleasure" of working with it many years ago, using a dedicated ASIC - the best available on the market at the time. The documentation was barely comprehensible - it had been translated from German to English by someone who clearly knew nothing about Profibus or electronics in general, and was barely competent in English. One critical chapter - containing the details of the register setup - was translated simply as "original German unclear".
Profibus may not be the worst choice of fieldbus protocol - but it is one that I would not recommend in normal circumstances.
CAN is a great choice when you want simple, clear and short telegrams between nodes. Now that it is common in microcontrollers, it is cheap and easy to implement. But that is only if /you/ have full control - if it is a closed network. It quickly gets horrible if you need to support DeviceNet, CANOpen, CAN Kingdom, or these other "high level" protocols on top of CAN. Instead of clear and simple sub-millisecond communication, you've got layers of negotiation about nodes and telegrams, complex device description documents, certifications, pretend "open" standards, and you have lost all hope of reliable timing.
Implementing your own scheme for larger telegrams over CAN is not hard when you have a specific task (typically everything in the system is short telegrams, except for firmware upgrades).
If you need something with higher bandwidth, jump straight to Ethernet. You can use standard networking and TCP/IP for ease of development (Modbus over TCP/IP handles pretty much everything you need for a typical fieldbus application, and you can add other protocols such as TFTP for larger transfers). Or you can use direct Ethernet frames for maximal efficiency.
The trouble with PoE is that it is vastly over-engineered, resulting in complicated and expensive parts. If you have full control of devices on each end, you can just pass 12V or 24V DC over a pair of lines on the cable. The easiest is to use one of the spare pairs (for 100 MBit), but even for 1000 MBit all you need are a few diodes to inject the DC into the data line.
But if you need /real/ PoE compatibility, that means a large clumpy module to handle the DC-DC conversion, and the negotiation protocol between the switch and the device to agree on voltages, current limits, etc. You also have to handle at least two standards, "mode A" and "mode B", for which lines will carry the power - and make sure your switch and your device agree. And then ever PoE switch manufacturer has a dozen variations, extensions and pseudo-standards of their own.
PoE could have been so cheap and simple that we would use it everywhere. Instead, it is far too complicated and expensive for the majority of uses.
The two standards bit does get a bit silly, but the problem with standardizing power distribution is that you immediately run into the question of how much power is available to the device. If you have a bus-like configuration, it gets worse because you now have to deal with unknown numbers of devices drawing unknown amounts of power. A good chunk of the power related complexity in USB and PoE is the management of that.
Now you could leave it strictly up to whoever's plugging things together, and require something like a "ringer equivalence number*" to be printed on each device, then the integrator just needs to total up the "RENs" and compare that to the REN output of the bus-hosting device. OTOH, that certainly would not be acceptable for any consumer(-ish) device today.
*And for those of you too young** to know what a REN is... Old POTS telephones used a higher voltage/current signal to drive the mechanical ringer than was used to drive the speaker and microphone circuits. Basically in "talk" mode, there was just not enough current on the line to move the mechanical ringer. Obviously if you had multiple phones, you needed more current to make them all ring at once. So a standard was established that a Bell 500 phone had a REN of 1.0, and a standard phone line would drive a load of 5.0 REN. So you could have five phones with "standard" load ringers on a line and have them ring reliably. A few phones had higher RENs, and many modern electronic phones have much lower RENs, but the idea was that the total of the RENs for all the phones on the line has to be no more than 5.0. REN boosters were available (actually still are) for situations where you needed more oomph. Sometimes called RAL outside the US.
**And... Damn kids, get off my lawn!
It is not about the cable being round, it is about the cabling length. With a coaxial cable it can be nodes_count times shorter, just a single cable running through all the nodes. And no switch necessary.
Then the 70V is somewhat too high, one cannot just use a trivial stepdown convertor as with say 12V for smallish things. I had designed PoE in our netMCA as an option on the board, well, was never used. Nobody had any thoughts on having a wall adapter, in fact need for a PoE capable router would have been more of a barrier in user perception.
Which is what it is of course. But this does not mean devices will not be connected over the net, our netMCA is one of those "things" quite some years before they coined the phrase. It will take just some more RAM on the MCUs, a few MB, and tcp/ip stacks will be practical even at higher speeds/transfer rates.
I would if I felt I had the muscle to enforce a standard :). It does not have to be 10base5, 10base2 (not sure, the 5mm coax cable thing) is plenty I think. I am not thinking hundreds of meters, rather a few meters to may be tens of meters. Then may be today we can do somewhat more than 10 Mbps over the coax cable, say 50 would be very nice. Using a
Obviously I agree with this. May be just 70V, isolated, would be much better. It is no rocket science to step that down in an isolated way nowadays.
It will take a while until we see MCU-s with an on chip PHY similar to the DP8392...